If the attacker do not know it's working (since there is no message saying the user has been locked out), they are unlikely to continue.
Even if they do (they might know for sure that a given username exists), it will be up to the deployer to detect that a username has been under constant attack (we need to make sure we communicate well in the logs) and: 1) change the username or 2) ignore the lockout for that specific username until the attacker gets bored.
This can be combined with blacklisting the IPs from attackers, however I do not know how complex it can be to add such an automatic blacklisting mechanism into deployments.
I like Morgan's proposal too.
If the attacker do not know it's working (since there is no message saying the user has been locked out), they are unlikely to continue.
Even if they do (they might know for sure that a given username exists), it will be up to the deployer to detect that a username has been under constant attack (we need to make sure we communicate well in the logs) and: 1) change the username or 2) ignore the lockout for that specific username until the attacker gets bored.
This can be combined with blacklisting the IPs from attackers, however I do not know how complex it can be to add such an automatic blacklisting mechanism into deployments.