In a word, no.
Without getting too much into the weeds here, when the client sends its certificate to the server, it then immediately sends a CertificateVerify message that is signed with its private key. The server, that which terminates this SSL session, validates this message with the client's public key. In order to do "SSL bridging", where the BIG-IP terminates the client side SSL as the server and re-encrypts to the backed application as the client, there are two separate SSL sessions. Absolutely NO device can send the client's certificate in this manner because the client (the proxy in this case) would never have access to the real client's private key.
ProxySSL in v11 could be an option because the process relies on an SSL man-in-the-middle technique to derive the same session encryption keys as the real client and server AFTER the end-to-end SSL handshake. This, however, requires a non-ephemeral (ie. RSA) key exchange. And since most browsers these days will prefer ephemeral ciphers - ciphers like DHE and ECDHE that provide perfect forward secrecy - ProxySSL (or any SSL man-in-the-middle for that matter) cannot work for these sessions.
More often than not, the applications that "require" client certificate also support other authentication options, like Kerberos. This is where an authentication proxy like APM can help you. APM can do client side PKI (certificate), server side Kerberos, and have access to all of the unencrypted traffic in the middle to perform intelligent load balancing based on the application layer content.
Nimbostratus
