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.
