I know I'm a year late, but I thought I'd reply to this.
If your policy was "after x login attempts for user y, lock out user y", then yes, that could be used to maliciously lock out users.
But another policy is "after x login attempts from IP address y, lock out IP address y". This way, all that's being blocked is connections from the malicious IP address, rather than a specific username. This is the approach a lot of big applications use, such as WordPress.com. Of course, users could get another IP address through something like TOR, but doing this still makes brute forcing password attempts painfully slow.
The only thing you have to watch is proxy servers, which, as we know, are widespread in education. If not properly configured, Apache (and, by extension, Moodle) could see every connection as coming from your proxy server's IP address. If there were a few incorrect logins coming from anywhere in your campus (which, knowing students, is likely), you could block access to Moodle from anywhere in your campus.
Since we're a big college and we use LDAP for logins, I'm going to be looking for a solution to this problem, probably using Apache/PHP logs and fail2ban.