Here's the professional way to do this:
"An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account."
The downside is that if my email account is compromised then my account with the service is also compromised, but if that's the case then most 'forgotten password' systems would be equally broken.
You'd want your query to be something like
SELECT password_hash = {password_hash} AS authenticated FROM accounts WHERE email = {email}
That way you'd be able to tell based on your result set whether the user exists, and if so if their password is valid. All with one query.
But, again, you shouldn't do this.
For example, on HN, it's trivial to find out whether a given username has an account -- just visit https://news.ycombinator.com/user?id=zck , and you'll see whether zck is a registered account.
On services like that, I don't see the harm in distinguishing "password incorrect" errors from "no user" errors, since that doesn't give you private information.
But on private sites, or if you're logging in via email? That's a different story.
(Android already has this. Android developers: Please use AccountManager. I am highly unlikely to create an account with you.)
I can't count the number of times I've just "oh well, nevermind" when I couldn't remember the stupid credentials I used with some application, or couldn't be bothered to create new ones. Not to mention the well-documented security problems with asking users to manage passwords.
Blech I say. Blech. I'm sad that it's 2014 and this is still unsolved.