Collision attacks have no impact on password hashing, although there can be some details depending on what you hash for. Roughly speaking, when we hash passwords, we may want to do two things:
Check that the password hashes to a given stored value: this is password verification (e.g. to know whether to grant login access to a server).
Compute a big symmetric key deterministically from the password: this is key derivation (e.g. to encrypt a file).
Password verification works only on resistance to preimages (hardness of finding a value m such that h(m) matches a given output). However, key derivation needs a bit more than that. Ideally, for key derivation, the hash function should behave as closely as possible to the mythical random oracle. We already know that hash functions based on the Merkle-Damgård construction, such as MD5 or SHA-256, are not random oracles (because of the "length extension attack"); however, we can use such functions in HMAC, which uses two nested hash function invocations precisely to avoid issues with the MD construction. But HMAC is "proven" secure only relatively to an internal property of the hash function (namely, the internal "compression function" should be indistinguishable from a PRF) and we know that this property is not fulfilled in the case of MD5, because otherwise collision attacks would not be feasible...
To sum up, when using MD5 for key derivation, we need to apply schemes such as HMAC-DRBG (a PRNG based on repeated HMAC invocations), which use MD5 internally. Such schemes are known to be strong as long as the hash function is strong, and while collision attacks do not directly apply, they show that this "strength" is not achieved. Thus, the guarantee is void. Nobody knows, right now, how to weaken HMAC/MD5, but we have the example of MD4: MD4 is thoroughly broken for collisions (collisions can be produced "instantly"), and there is a known attack on HMAC/MD4 which is quite expensive but nonetheless much faster than the theoretical 2128. The attacks on HMAC/MD4 do not exploit collisions, but build on differential paths which are the same source from which collision attacks have been designed. Therefore, it is highly suspected that HMAC/MD5 is not as strong as, say, HMAC/SHA-256 (even when truncated to 128 bits).
Correspondingly, for key derivation, do not use MD5. It would not be broken right away, but it is still looking for trouble. There is no need to immediately migrate existing systems which use MD5 for password hashing, but for new designs, you should avoid it.
Of course, when hashing passwords, regardless of the intended usage (password verification or key derivation), you shall apply salts and configurable slowness. A password is by itself a weakness because of biological limitations of the human brain which manages it. Salts and configurable slowness are ways to cope with it: salts thwart parallelism (the attacker cannot share attack costs between several password instance -- e.g. through precomputed tables such as rainbow tables) and slowness defeats Moore's law (computers get faster over time, but human brains do not). So you would not want to hash a password with "just MD5", but rather use a dedicated password hashing function such as PBKDF2 or bcrypt. PBKDF2 internally uses a hash function, e.g. MD5. It so happens that MD5 (like SHA-256) maps very well on the computing abilities of GPU, which makes it a questionable choice for this job, and bcrypt is arguably better (see this answer for details).