I could not see any reason you provided to separate the username from the password form. If you would validate username and password independently, that would make some sense, especially if you noticed a username does not exist and offer a flow of creating a new account.
As it seems you aren't, and you cannot validate username/password independently (and I do understand why), the most obvious course of action is to keep it safe and oldschool, and provide username/password fields on one screen. Should authentication fail, the messaging needs to imply that it's either the username or password that's wrong.
Which field to focus once the error message has been displayed? People mostly mess up passwords, especially if they are hidden behind dots or asterisks, so it would be user-safe to focus that field. If you think the user might have mistyped the password, you can blend in a hide/show toggle for the field which would unscramble the password, allowing the user to double check whether the password entered was the one they wanted. This is common for situations where the user doesn't realise caps lock is turned on, they fumble passwords on mobile, or if they use different keyboards from the one active as language (some keyboard languages switch the position of Y and Z, for instance).
If your username is different from an email address, then you need to provide a mechanism to not only recover an account from the username, but also to type in the email address the user registered from to recover both the username and password.
It is also considered good to not hide the "Forgot password" from the get go, as the initial step might already be a place where the user does not remember their access details. This is a common case if someone accesses the service through an email they received and they cannot recall their initial login/password data. In those cases services sometimes rely on tokens embedded in the link that provide one-time access. Security implications dictate that if a person has access to their email and this particular email arrived, it's likely they are the owner. Security level-wise, this depends on the particular service and whether it's wise to allow such access. Financial services or anywhere where a person's identity can be severely compromised usually don't allow token access.
Hope this helps!