That's a decent set of mitigation measures. Having a per transaction spending limit is probably the most important one.
I'll point out one possible attack that still quite feasible:

1. Terminal sends the actual requested amount to the card
2. Terminal shows the response code and displays it to the user. (So far so good)
3. Terminal immediately cancels the transaction and tries to unlock the card. During that time, the user enters his PIN, oblivious to what is going on.
4. The user presses OK. The terminal now knows the PIN.
5. By now the card has unlocked itself. The terminal sends a larger amount for payment, ignores the response code, and sends back the PIN.
6. Card authorizes a larger payment.

Of course this requires that the lockout period be not much longer than the time taken by the user to enter the PIN. But the terminal can nicely slow down the user in a variety of ways, without looking too suspicious:

1. Add a "confirm amount?" screen to check the payment quantity, after having sent the payment request to the card.
2. Mild delay after pressing each key/hard to press keyboard.
3. Pretending the PIN was mistyped the first time and asking to try again.
4. "Connecting to network... please wait..."

You could try to increase the delay to be closer to a minute, but it looks like you can't track time when you're not plugged into a terminal. Tricky.