Generic error message for wrong password or username - is this really helpful?

No, you are correct that at some point during efforts to prevent attackers from determining valid user identities you will either have to lie to them or provide exceptionally vague error messages.

Your app could tell a user that "the requested username is unavailable" and not be specific as to whether it was already in use or just didn't meet your other username requirements (length, character usage, reserved words, etc.). Of course, if these details are public then an attacker could work out that their guess failed due to the account being in use and not due to invalid format.

Then you also have your password reset system. Do you accept any username/email address and say a message was sent even if that account wasn't in your database? What about account lockout (if you're using it)? Do you just tell the user that their credentials were invalid even if if they weren't but instead their account was locked out, hoping they contact customer support who can identify the problem?

It is beneficial to increase the difficulty for attackers to gather valid usernames, but it typically is at a cost of frustrating users. Most of the lower security sites I've seen do use separate messages identifying whether the username or password is wrong just because they prefer to err on the side of keeping users happy. You'll have to determine if your security requirements dictate prioritizing them over the user experience.

You're making the assumption that the system actually knows which field was entered incorrectly. There are several reasons this is not necessarily true.

One possibility is that it's a side effect of implementation. A simplistic method of looking up logins in a database might look something like (using :n for parameters supplied by the user):

SELECT 1
  FROM users
 WHERE username=:1 AND
       password=HASHING_FUNCTION(CONCAT(:2, salt))

If you get an empty result, you know the login should fail, but you don't know why unless you do something more complicated or make another query. So sometimes it may just be laziness or a desire to go easy on the database, rather than a conscious security decision.

But even if the implementation can distinguish between an nonexistent user and incorrect credentials, you still have the situation where a user enters their password correctly, but the wrong username, and that happens to be a user that exists (with a different password). Then, if the user got a message saying their password was incorrect, that would be wrong. So unless the specified username doesn't exist, the system can't actually know if it was the username or password that was wrong.

In general, it is harder to brute force a registration page than it is to brute force a log in page, so we benefit from this additional cost. But, in concept, you are correct. There are other ways to enumerate usernames than log in page messages.

It is simply 'Good Practice'(TM) to keep log in failure messages generic in order to make it harder for attackers to glean good accounts from bad. Using a brute force tool, it is trivial to try random names, and then when the error message changes, to start brute forcing that username.

But, as always, you need to balance usability with threat reduction.