Short answer: Yes and no.
First of all, let's get things straight. How does key-based authentication work in SSH anyway? Once the SSH connection reaches the authentication phase, the client signs a bunch of data (this includes the session identifier) with its private key, then sends the signature to the server to verify it.
Signature verification pass -> Authentication successful.
How does a MiTM attack in this case then? The attacker sits between you and the server. For a successful attack he needs you to start a session with him, and he needs to start a session with the server. Whatever you send to the server, will actually go to him and he has the ability to modify it and send it to the server, and whatever the server sends you will actually go to the attacker and the attacker can modify it and send it to you.
Have you noticed something interesting? There are two sessions here (keep this in your mind). Each session is going to have its own session identifier because the generation of the session identifier isn't determined by the server or the client alone. In other words, the signature you use to authentication to the attacker will be different from the signature the attacker has to use to authenticate to the real server.
The attacker doesn't have the client's private key, meaning it won't be able to come up with a signature that the real server will accept. That's why this kind of full MiTM will is not possible.
So it's safe to disable host key/fingerprint checking, right? Not exactly. It's true that because the attacker won't be able to authenticate to the server, he won't be able to execute malicious commands on it. BUT
Remember when I told you about the two sessions? The attacker won't be able to establish session with the real server, but he can easily make you establish a session with him. The attacker will simply accept whatever signature you give him and trick you into thinking that you're now connected to the real server. You'll send him commands (and possibly some process-specific passwords) and he'll happily reply with whatever makes you happy.
Granted, there's no real danger to the server here since those commands aren't really reaching the server. It's just that there's no telling what you'll actually be sending the server (now the attacker). You might send keys, passwords (think, when you modify your password the server will ask you for the current password), and other sensitive information.
Bottom line is: If you're willing to accept the risk of connecting to a fake server that will know what you're sending to the real server, then disable host key/fingerprint checking. Otherwise, keep it enabled.