So for login: always say "email or password is incorrect".
And for register: as he said, always say "we sent you an email to verify your email".
Making your validation errors cross mediums and a wait for an e-mail to delivered is an unnecessarily hostile user experience.
One problem with that is that when users are given the option of an arbitrary username, they tend to be much more likely to forget that username than they are the email address they use daily. So, you need some way of resetting their password and letting the user recover their username. In some cases, you could pair that with other identifiers, like their name, phone, social security number, etc. However, then you are just trading the email as an identifier for something else, which you would also need to check during registration.
For this reason, I've found that moving away from a username and just relying on an email for a login makes managing multi-user sites a great deal easier from an admin side.
I agree that e-mail makes for a better login experience, but if exposing who uses your site is too much of a privacy concern, I'd rather move to usernames than have to implement awkward user experiences to never reveal whether someone is a user or not.
Although to the point of this article, they will then happily tell you you can't use an email during signup, so it is a mixed-bag.
I suppose if you allowed multiple usernames per email, you could just email them all the usernames that they have on that email address when they forgot their username, but that seems like a clunky setup. It probably depends a lot on the service though, as someone posted a link to a discussion from 2014 about Amazon's reasoning for allowing multiple emails elsewhere in this thread, which makes a bit of sense for their use-case.
Suppose another website has a security breach, revealing many names and passwords. User John Doe used a password of "foo", so an attacker starts trying combinations like jdoe/foo or johnd/foo or john_doe/foo, looking for the same person reusing a password on your site.
By denying them information about which login names exist, it's harder for the attacker to either zero-in on the correct username (and try alternate password variations) or to be certain that they've got nothing and that it's time to move on.
You could argue it's security through obscurity - I'd say preventing leaking data.
1. Identify people who are gay/bi (e.g. signed up to grindr)
2. Identify political affiliations (depending on site)
3. Identify health issues (signed up to a mental health forum, or cancer support group, etc)
These things people might be happy others knowing, but I hope you can at least see some cases where you might not.
Say I've got a leaked password database for foo.com and know that the user bob@gmail.com uses the password "tomato1". If I try using his credentials to log into bar.com and get the message "username or password is incorrect", I'm just going to try the next user on the list. If I get the message "incorrect password", it makes sense for me to try "tomato2", "tomato3" etc. If I know that your password policy requires eight characters and a capital letter, I'm going to try "Tomato11". This is obviously trivial to automate.
You can't protect your users against credential-stuffing attacks if they use the same password everywhere, but you can offer them a small layer of protection if they use the same password with minor variations.
As others have pointed out, mere disclosure of the existence of an account could be a serious privacy breach in itself.
"email or password is incorrect" is bullshit is right.
Given that, who cares what error message you display, as an attacker I only need to be able to find out weather a system has an email or not, and the sign up screen is a perfect oracle.
For this I would recommend adding the mention "your username will be publicly visible" during the registration process.