It is a bit difficult to judge if your scheme is reasonable or too much because it fails to provide any information on what the application does or what the value of the resource being protected is. Your security should be matched to your risk analysis i.e. the likelihood of attackers and the consequences should an attack be successful.
From your description, my main concern would be that you have built in a facility which would assist an attacker in performing a denial of service attack on your site. This may or may not be an issue, depending on your site and how the services are used. For example, if the site is one where users first authenticate and then receive some sort of token which they use for subsequent connections and if that token has a reasonable lifetime, then potential DoS issues may not be a significant problem (assuming most users are already authenticated and are able to continue to use the service). On the other hand, if the token has a short life time and users authenticate quite frequently, then this could be a problem.
From your description, it isn't clear that this is a 'real' threat your trying to protect against or a theoretical attack i.e. an idea someone has had and has decided to protect against. Do you have any evidence or reason to believe the site is likely to be targeted by a botnet style attack as you describe? While the attack type your describe does exist, a vast number of sites/services out there never see such attacks or seldom see them. It this is the situation for your site, it is likely that all this additional complexity brings you is possible inconvenience for legit users who forget their password and added complexity in your system, which has even more potential to create problems or hide vulnerabilities. Increased complexity can easily lead to increased false positives, which may well create frustration with your users and result in lost business.
As an example, just recently I assisted a company with diagnosis of a problem they had with their web application. Users were reporting increased frustration with lost sessions and having to re-authenticate too frequently. The problem turned out to be related to a security feature built into the system.
The application used a JSON web token to manage authentication/authorisation. The user would initially connect and provide their username/password etc and get a token which they could use for subsequent connections. The token had a 24 hour lifetime. All that was fine.
For added security, the token recorded the user's IP address and on each access tot the services, after decrypting the token, the service would check that the IP address recorded in the token was the same as the IP address the connection was coming from. On the face of it, this seemed reasonable. The app was mainly used from inside the corporate network. The company had a large site.
A recent network upgrade at the company resulted in the installation of approx 3000 new wirless access points and a new configuration of the wired and wireless network so that it used 802.1x across wired and wireless networks and a move from assigning IP address based on geographical location to one based on user role. One of the advantages of the new setup is that you could move around the organisation and keep your wireless connection active. As you move between access points, you may get a new connection and that new connection may have a new IP address, but to the end user, it looks like one connection. You can probably see where the problem was.
Due tot he change in IP address, the auth token no longer passed the IP test. The problem was an assumption that the user would retain the same IP address the the lifetime of their connection. However, there was also another more subtle issue. As this application is used on an internal network, which is fairly well locked down with quite a reasonable level of security, the IP check was unlikely to be actually improving security at all. The idea of the IP check was to add additional protection against session hijacking by someone who was able to steal the users token. Although this can be a real risk in some environments, in this specific environment, this was a low risk and the protection was not of any real benefit. Worse still, the data which could be accessed by the application had low value - it was information useful to staff, but was not particularly sensitive and the consequences for unauthorised access were low. This was an example of a security measure being implemented which was based on a theoretical threat rather than a real threat in the environment.
The point is, you need to assess whether your control is really addressing an actual threat or whether it might be a reasonable idea which isn't of any real benefit to your environment and could potentially have a negative impact on legit users. Is the type of attack you describe and are protecting against a real threat in your environment? What would be the consequence if that type of attack succeeded? Will the potential impact on legit users be acceptable to the business? If you enforce strong passwords and use good hashing techniques, how likely is a brute force attack likely to work anyway? I suspect that your measures may be excessive and possibly not providing any real benefit, but that depends on the application.