In the process of building what I'd like to hope is a properly-architected authentication mechanism, I've come across a lot of materials that specify that:

1. user passwords must be salted
2. the salt used should be sufficiently random and generated per-user
3. ...therefore, the salt must be stored with the user record in order to support verification of the user password

I wholeheartedly agree with the first and second points, but it seems like there's an easy workaround for the latter. Instead of doing the equivalent of (pseudocode here):

salt = random();
hashedPassword = hash(salt . password);
storeUserRecord(username, hashedPassword, salt);

Why not use the hash of the username as the salt? This yields a domain of salts that is well-distributed, (roughly) random, and each individual salt is as complex as your salt function provides for. Even better, you don't have to store the salt in the database -- just regenerate it at authentication-time. More pseudocode:

salt = hash(username);
hashedPassword = hash(salt . password);
storeUserRecord(username, hashedPassword);

(Of course, hash in the examples above should be something reasonable, like SHA-512, or some other strong hash.)

This seems reasonable to me given what (little) I know of crypto, but the fact that it's a simplification over widely-recommended practice makes me wonder whether there's some obvious reason I've gone astray that I'm not aware of.