In "usual" SSL, the public and private key pairs are on the server side, not the client. The client uses the server's public key (as found in the server's certificate, that the server conveniently sends to the client during the first connection steps) but does not need to own a public/private key pair itself(*).
Of course, this implies that while the client obtains from the server's certificate some reasonable guarantee that it is talking to the genuine intended server, the server has no idea whatsoever who the connected client may be. When there is no client certificate, SSL ensures only one-way authentication. If a server wants to authenticate clients, then it is up for the client and server to run some extra authentication protocol within the SSL tunnel. That's exactly what happens with Web browsers and HTTPS servers: the SSL layer convinces the client that it is talking to the right server, and then the client shows the user's password to the server.
(*) If the client and server agree to use a "DHE" cipher suites, then indeed both the client and server create temporary Diffie-Hellman key pairs, that you won't see; the corresponding public keys will not appear as part of certificates either. If the client and server use a more common "RSA" (non-DHE) cipher suite, then the key exchange is really the asymmetric encryption of some random bytes generated by the client, using the server's public key, and there is no public/private key pair on the client side.