Your description is a bit confused; I see you are talking about "signing with the public key" which is analogous to "encrypting with the private key", i.e. a widespread but flawed explanation which does not actually work with real asymmetric cryptographic algorithms as they are used in practice.
Nevertheless, it can be said that what you seem to suggest does not do what you believe it does; or, rather, SSL is already more secure than you believe. When the attacker knows the private key of the server, then he can impersonate the server: the client talks to the attacker, believing that it talks to the genuine server. Similarly, if the attacker knows the private key of the client (assuming that the client has a private key, and the server asks for client authentication with a certificate), then he can impersonate the client when talking to the server. This is generic. However, in order to pull off a true Man-in-the-Middle attack, the attacker must do a double impersonation: he must simultaneously impersonate the server (when talking to the client) and impersonate the client (when talking to the server).
With SSL as defined by the standard, when the server request a certificate from the client, a true MitM is not feasible unless the attacker knows the secret keys of both the client and the server. The problem you allude to ("server only checks the authenticity of the client") does not actually exist. Therefore, your proposal cannot solve it (there is no possible solution for an inexistent problem).
In fact, somehow mixing the client's public key may make things worse. Ideally, the server's public key should not be used for key exchange either. The reason for that is often called forward secrecy (PFS). If the server uses a classic RSA-based key exchange, and the attacker, later on, steals a copy of the server private key, then the attacker can decrypt past recorded sessions. This is bad. But there is a fix in SSL, called "DHE" as "Ephemeral Diffie-Hellman". When using DHE cipher suites, the actual key exchange uses DH key pairs that both client and server generates on the fly; the server merely signs its DH public key using its permanent private key. This provides PFS because the server never stores its DH private key anywhere, making it presumably immune to ulterior theft.
We may note that, in SSL, the client's key, when used, is only for a signature; and that is good. It means that if the client's private key is stolen, previous sessions still remain confidential. Using a DHE cipher suite enables the same desirable property on the server side. This enhanced security is not obtained by "using the client certificate to generate the premaster key"; quite the contrary indeed. It is achieved by ceasing to use the server certificate to generate the premaster key.