For a description of how SSL works, see this answer. To make the story short, SSL begins with a special procedure called the handshake in which client and server exchange "handshake messages". A lot of cryptography is involved, to the effect that at the end of the handshake, client and server share a common session-specific secret value, from which they derive keys for encryption and integrity checks of data in both directions. The point of SSL is to establish a bidirectional tunnel for arbitrary data; that "arbitrary data" is called application data in SSL terminology.
HTTPS is "HTTP within SSL": a SSL handshake is made first; and then, plain HTTP traffic (HTTP requests with their headers, and corresponding responses) are conveyed as "application data" through the SSL tunnel. When a Web site requires client authentication, this process occurs at the HTTP level, so, from the point of view of SSL, as "application data". The user password will be part of that application data.
However, all the application data is encrypted, since that's what SSL was designed for. As an outsider, you won't be able to read it, because that's the whole point of SSL. SSL protects the client-server traffic against eavesdroppers, including yourself. You won't see anything except "encrypted application data".
To "see" the inner traffic, the HTTP requests and responses (and, thus, the user name and password contained therein), you need to break through the SSL layer; Wireshark can do that, but only if you give it a copy of the server private key (the server private key might not be sufficient for that, when client and server agree on a "DHE" cipher suite, but that's not the situation you encounter). See this page for some documentation. It would be quite alarming if breaking through SSL was possible without a privileged access to at least some client-side or server-side secret data...
