If the Honeychecker system has to be secured in order to guarantee that the whole system is secure, why not store the encrypted passwords there in the first place ? It seems to be manufactured complexity.
It's classic engineering redundancy.
A. It doesn't do a lot to 'secure' the password credentials (in the way most people think of the term). It just tells you that someone tried to login with a honeywords. What happens then is a difficult process.
B. It's only belt-and-suspenders redundant to the extent the difficulty of cracking the honeychecker server is independent of the regular login server. It's certainly beneficial that it has a much simpler API, but if your honeychecker is just a different Ruby Gem hosted on a different Linode (for example) the benefit are lessened.
It's possible that the password compromise is affected through other means as well (backups, database compromise, etc.), In which case the honeychecker van help validate this.
A similar approach would be to have sentinel accounts which aren't ever accessed, and which would trigger alerts if they were.