I think both combination are same.
I incline to the view of TomB as well. I barely remember all the usernames I have had so far for logging in! 
and I tend to forget them in just a few days!
You don’t even need a CAPTCHA to do that. Simply building in a time delay after an invalid login attempt before another attempt can be made is sufficient. Real people would take some time to realise that they got their password wrong and to retype it correctly. If you lock their account for just under that long whenever an invalid password is entered or an attempt is made to login while it is already locked then any attempt to break in would need to build in a delay between tries of at least that long or it would only be able to break in if the first guess turned out to be right. If they do find out about the lock delay and allow for it then it would then take them thousands of times longer to break in than if the delay wasn’t there which would make it far easier for them to go elsewhere.
@kalon, I have always wondered about gmail (for example). Try type in loren@gmail.com (not me) and it says it is taken. Now you know a login name and nothing but a possibly insecure password stands between you and their account. I know that after a certain amount of log in attempts are made it switches to a captcha but that just slows you down.
Even on this forum it’s pretty easy to find a login username to throw some passwords at 
great point TomB, I actually constantly have this problem myself, when my fallback username is not available, chances are I will forget the third one within a day.
I think its pretty clear that if you have to have screen names / usernames, then register them, but get people to login with their email address which is a value which is more consistent across all their registrations.
Hashing the password will provide better security in that it will not be possible for anyone with direct access to the database (eg the staff at the data centre) to read the passwords. Not that the staff there should be doing that and anyone who did would probably get into big trouble over it. The possibility of it happening is extremely small but still not completely impossible and so protecting against it is still improving security.
The main issue is where someone uses the same password for multiple sites. If someone uses the same password on your site as they do for their bank account and someone can read the plain text copy of that password from your database, they could then use it to log into that person’s bank account and empty out the account.
If you use your own salt to hash the passwords then there is no way for someone with access to the database to tell what the password is and so your site can’t be used to gather passwords to try on other sites.