If you use the password as "salt" then you are not using any salt at all; you are just hashing the password.
If two users choose the same password, they end up with the same hashed password. That's what is often told as if it explained the problem, but it seems that most people get it wrong. They imagine that this means "collision", which, for some reason, is considered by many to be a bad word when talking about password hashing. But that's wrong, and not the point.
The point is determinism. Suppose that I, wantonly, grab a copy of the hashed passwords for 1000 users (e.g. I retrieved an old backup tape from your garbage bin). Then I can "try" potential passwords: I hash a potential password (using the password itself as "salt") and then I look up the value among the 1000 hashed values. This means that by paying the computational price of one hashing, I actually try one thousand user+password pairs. I am attacking one thousand of hashed passwords in parallel, for the same cost as attacking a single one. This kind of parallelism can express itself under several guises, including rainbow tables.
We really prefer it when attacking 1000 hashed passwords costs 1000 times the cost of attacking 1 hashed password. To do that, you need real salts, i.e. salts which are distinct for distinct users, even when they happen to use the same password -- and, actually, when they potentially use the same password. When there is no real salt, the parallel attack works not because some users do choose the same password, but because if they had chosen the same password then they would have obtained the same hashed value. They don't actually need to choose the same password to trigger the weakness.
Using the user name as salt is much better. It is not good, mind you; but still better. What is even better, to the point of being actually decently secure, is to use random salts.