It's easy enough to read 8 bytes or so from /dev/random on a Unix box, and 8 bytes is plenty of salt. If you don't have something so simple as a device file from which you can read bytes, then rand() or the pid divided by the current time and encoded Base64 (or, heck, MD5) might work for you.

As for storing the salt, there are a number of options. Some applications stick it in a separate field just for the salt. Some use the first X or last X characters of the password field to store the salt (which means, of course, a fixed X characters of salt). Some put a colon, comma, slash, or some other character not appearing in the hash (or delimiting fields in the file) between the hashed password and the salt.

Some take advantage of the fact that certain hashing algorithms produce fixed-length hashes, and stick the salt at the end of the password field. MD5, for example, creates 128-bit hashes usually represented as 32 bytes in hex. You could say the first 32 characters of your password field (or the last 32, or the first 16 and last 16, whatever) bytes are the hashed password, and that anything else is the salt.

Appending or prepending the salt to the plaintext of the password before hashing is the simplest way to improve the chances of avoiding attacks built around rainbow tables. They still do little against true brute-force attacks. It's also possible to get creative with salting, like having the first character of the plaintext password determine whether the salt is prepended or appended, having characters of the password and salt interleaved, or splitting the password in half and putting the salt in the middle before hashing. Again, these cute tricks might provide additional help against table-based attacks, but are not going to stop a brute-force attack.

Some applications will use some other field (or combination of fields) unique to the user as the salt instead of a random value. If you're using some other field(s) as the salt and not storing it separately from those fields, be aware that any updates to those fields require rehashing the password with the new salt at the time of the update.

MD5 should be good enough, for some value of "good enough", for passwords. This is more true with the use of a salt. Be aware, though, that for longer strings it has been found to have fairly quickly reproducible hash collisions. The md5 article has links to papers about its strengths and weaknesses. I personally wouldn't worry about passphrases colliding, as it appears the collision-finding methods are based on longer files being hashed down to 128 bits simply losing too much Shannon entropy in the hashing process (since minimum message lengths are noted for the methods) and some impressive mathematical analysis of the peculiarities of how that happens in MD5. At the average length of most user-chosen passphrases, a dictionary or rainbow table attack is a bigger concern. I'd appreciate anyone with better cryptographic information or a better understanding of the issue correcting me.