tldr: The approach you outline fails do address the actual problem, use a separate application and a secure authentication scheme.
While you are right that keeping account credential information with the rest of the lot (i.e. whatever your application actually uses when it's not authenticating users) is a bad idea (tm), the approach to just have a second database falls short to solve this problem and here's why:
The threat you are trying to mitigate is either:
- compromise of the database or
- compromise of the application
If (1), depending on what information is inside the database and how it's used (i.e. what the trust level of the application regarding the db is), I am quite confident that (2) will be possible to achieve.
If (2), having a separate database your application connects to will be useless at this point; the attacker has access to the applications credentials and thus access to both databases and can dump and use them, effectively as if they were a single database.
So, from that point of view, your proposed sollution seems like overkill because the cost outweighs the benefits. Yet, there are viable ways to doing this:
Authentication is petty known task for applications to do. This is the reason software exists that takes care of only that task.
The idea would be to have an abstracted web service (or the like) that only processes authentication and responds with a token that the actual application accepts (because it trusts the service to authenticate users, that's it's job).
One example of such a scheme would be OAuth2; you have one service for authentication and another one to serve your actual business needs. Hence you can abstract from sensitive data where you do not need it, only using the user handle your authentication platform provides.
This is independent of using multi factor or not, by the way; even if you're just using username/password auth, you gain benefits (for example, you do not leak all your customers credentials when the application gets exploited).