Yes, the account should be locked out.
The reason is that the successful login could be from the real user, and the failed logins could be from an attacker. The fact that the real user has logged in should not reset the counter for the attacker. Of course you could track sessions and only lock out the user if they are on a different session than the real user, however here there is more risk of implementation bugs meaning you could inadvertently introduce something that allows an attacker to work around the lockout. With security it is often best to keep things as simple as possible.
You should also rate limit repeated attempts from the same IP address as that will help protect against a horizontal attack against different user accounts.
The above is comment on your current proposal, however I would also go for an increasingly delayed response rather than locking out.
Login Attempt Artificial Delay
2 1 second
3 2 seconds
4 4 seconds
5 8 seconds
That way the real user will be able to log in during a brute force on their account and the attacker cannot cause a Denial of Service on the legitimate user. For longer delays you could display something to the user to show that their login is in progress so they would not be tempted to click again. Of course you do not want the maximum delay to be much longer than several seconds, however adding an artificial delay across threads will delay an attacker. The difference between slowing down login and showing an account locked out message is that the real user will not have to keep submitting their login details - they just need to be patient while login is progressed.