Since the whole system turns on having a hardened system which can distinguish honey from true passwords, it seems like you could get a significantly improved level of security by replacing it with a hardened system that hashes passwords with a secret, long pepper, which vastly increases the amount of time necessary to crack even trivial passwords.

The alarm trip is nice, but if you assume that you have a hardened black box that you can put data into and get data out of, you could use that to increase the complexity of the given hashes to a degree that they would be uncrackable (offline) in the first place, and standard throttling (and alarming) makes online brute-force attempts trivially detectable and blockable.

Assume that you have a user whose password is "1234", and the salt is "5678". Let's assume the system is naive and uses SHA1 for hashing.

Given these two pieces of information, that password is trivially crackable. Not a problem. However, let's now assume that we take our password and feed it to our black box, which hashes it with a 1024-bit pepper, and feeds the resulting hash back to the web app. Assuming the pepper's secrecy is protected, the password's complexity is now so ridiculous that even with all the computing power in the world, you wouldn't be able to brute-force the hash for the password "1234" before our sun explodes.

Now your passwords are mathematically protected against breach, which is arguably more valuable, since it means that the attacker can't take my email address and my six honeywords + real password and plug them into various sites trying to get a hit - those other sites won't know which are the honeywords, and won't trip any alarms when the wrong ones are used, but given the tiny quantity of passwords to try, attackers are sure to get hits. Why not just prevent them from ever discovering a usable password in the first place?

Or, if you wanted the honeypot aspect to be preserved, make your black box take a password, perform some transformation on it, then hash it. For each user, we'll generate and store (in the black box) a one-time pad that we use to transform (/encrypt) their password, then hash it. Password complexity isn't affected, but without the pad, the original password is unobtainable. My bad user uses a 4-character password "abcd" which maps to "hvz5", which I then hash. An attacker who steals the hash list can brute-force "hvz5" easily, then attempt to log in with it, and my system can detect an that the attacker is attempting to log in with a transformed (and thereforce, obviously derived) password and raise the alarms. The system allows for detection of compromised logins without ever risking exposure of the user's actual password to an attacker.