User name enumeration?
Let me give you an example of a hypothetical yet very plausible scenario.
There is an aspiring hacker named Bob. One fine sunny morning, Bob found an SQL injection flaw in a popular social networking site named HandBook. Using said SQL injection flaw, Bob managed to dump the a list of email addresses and passwords of accounts registered with HandBook. Given that HandBook has a shitty security team, all the passwords are hashed unsalted with MD5. Cracking open his trusty rainbow table, Bob manages to recover the plaintext passwords of 86% of the user accounts.
What does Bob do next? Bob knows that 86% of the people on HandBook are teenagers. What do teenagers love more than one social networking site? Two social networking sites of course! Bob decides to try out all the email address and passwords combinations he managed to crack against the authentication service of a second popular social networking site, Chatter. Given that teenagers are teenagers, they do not have strong password policies. Bob manages to access 76% of the user accounts simply by trying the same password or a close variant. He was able to accomplish this very quickly since Chatter's login form kindly notified him when he was trying to login with a non-existent email address.
Is this a flaw? Yes, potentially. I mentioned this in another one of my answers. It has been pointed out that this might not be a major issue if the usernames of registered accounts can be enumerated in another fashion, for example through the registration page. However, many registration pages are protected with CAPTCHA, which makes automated attempts against it that much harder.
This is old lore.
In older times, people were using mainframes and very poor passwords, so protecting account names was "important": if an attacker knew the name of an actual user, then he could try passwords, and, at that time, trying a few dozen passwords tended to work.
Of course, this was unsatisfactory, because user names are not really secret information. It was much better to have strong passwords.
Nowadays, hiding user names is less important, and also impossible in some contexts. For instance, when a user registers on some Web site, using a "name" of his choosing, then the Web site MUST warn him about duplicates, and that's unavoidable; the site cannot tolerate two users with the same name. In that context, it is not feasible to really hide user names; thus, hiding user names had better be pointless. As @Terry mentions, CAPTCHA on registration pages may make user name enumeration harder to do automatically (but "harder" is not the same as "hard").
So failed login messages which do not distinguish between a non-existent login name, and a bad password, are still in wide usage, but more for the sake of tradition than for a strongly rational reason.
Note, though, that there are botnets out there which try to replicate by trying SSH logins on random IP addresses, with "common user names and passwords". Just inspect the auth.log file of a Linux server, you'll see these attempts. Such botnets have done that for years. They might do this out of a sense of Tradition (there is no reason to believe that evil people are more competent at what they do than non-evil people), but it is possible that this kind of brute force really works with a non-negligible success probability; and a failure message which makes a distinction between a bad login name and a bad password can only help these botnets.
Therefore, while the whole notion of avoiding to leak user names is mostly an historical remnant from older times, it can still have some value in some corner cases, mainly mass-brute-force by a mindless attacker.
If an attacker is doing a social engineering attack. The attacker could put a victim email address inside the login form. Then we will be able to know if the victim is registered or not under a specific email. If the victim is registered to a web site, the attacker would create an account on that web site and he would try a social engineering attack. I don't think it will stop the attacker but by not giving the message "The email you entered does not exist", it should slow down the attack.