A man-in-the-middle attack is when an attacker inserts himself between client and server, and impersonates the client when talking to the server, and impersonates the server when talking to the client. "Impersonation" makes sense only insofar as there is an expected peer identity; you cannot impersonate an anonymous client.
From the point of view of the server, if the client shows a certificate and uses his private key as part of a CertificateVerify message (as described in the SSL/TLS standard, section 7.4.8), and the server validates the client certificate with regards to a set of trust anchors which does not include an hostile or incompetent root CA, then the server has a guarantee that it is talking to the right client (the one identified by the client certificate). The guarantee holds for all subsequent data within the connection (it does NOT extend to data exchanged prior to the handshake where the client showed a certificate, in case that handshake was a "renegotiation").
This means that a client certificate indeed protects against the specific scenario of a rogue CA injected in the client trust store. In that scenario, the "attacker" succeeded in making the client trust a specific root CA that is attacker-controlled, allowing the attacker to run a MitM attack by creating on-the-fly a fake certificate for the target server (this is exactly what happens with some "SSL content filtering" proxies that are deployed in some organizations). Such MitM breaks client certificate authentication, because what the client signs as part of a CertificateVerify message is a hash computed over a lot of data, including the server certificate -- in the MitM scenario, the client does not see the "right" certificate and thus computes a wrong signature, which the server detects.
From the point of view of the client, if a client certificate was requested by the server and shown by the client, then the client knows that the true server will detect any MitM. The client will not detect the MitM itself; and if there is an ongoing MitM attack, then the client is really talking to the attacker, and the attacker will not tell the client "by the way, you are currently being attacked".
In that sense, a client certificate prevents a true MitM (aka "two-sided impersonation") but does not protect against simpler frauds (one-sided impersonation, i.e. fake servers).
Bottom line: In the presence of SSL with mutual client-server authentication (both send a certificate to the other), a successful MitM requires the attacker to plant rogue CA in both the client and the server. However, if the attacker can plant a rogue CA in the client only, the client is still in a rather bad situation (even though a complete MitM is thwarted).