It is called a 'resource starvation' attack, that applies to any situation where the work on the part of the attacked party is greater than the work required by the attacker.
Hashing is actually very 'cheap' compared to the time to execute the database lookup to confirm it.
There are a few mitigations you can apply. In the event of an attack you first off want to increase the 'cost' to the would-be attacker. CAPTCHA's can help with this, but they have a negative impact on accessibility generally. So the best option is to have them 'turned off' and then enable them based on a server side trigger.
You can limit requests but it's easy to get around. You can globally delay and limit the processing of each login request so each IP can only issue one login request at a time and has to wait before the server even begins to process it. If they issue another request before the request is completed then you can dump it cheaply. But this has the downside that it is more complex to implement and that it could affect clients behind a NAT router. Everyone else would be happy to wait a couple of seconds with a 'please wait' type dialogue - again it ramps up the cost for the attacker as they require more sources to attack from.
If your system can make you aware of an attack in real time then you can work with your hosts to block or limit problem traffic (for example from regions you don't supply or serve) so the attackers essentially saturate their own routes into your servers or direct the attackers into various sinkholes and honeypots.
Ultimately it comes down to being just like any other distributed denial of service attack in that it's a case of managing load. Ultimately if it's a cloud based system you might want to just spin up more capacity (although you need to be aware of the costs involved).
Ultimately the answer is to go read up on security to understand the whole landscape. Have a look at Security.SE:If you could only have one book on web security, what would it be? for suggestions.