Certificates use asymmetric cryptography: here, the client generates a public key, gets it "authenticated" (signed) by the server, and later on proves his knowledge of the private key to the server (as part of certificate-based client authentication in SSL).
Certificates are useful when the certification authority (the party which "issues" the certificate, i.e. computes the signature on the certificate) is distinct from the party which uses the certificate (the one which authenticates the client afterwards, by looking at the client certificates and having the client use his private key as part of certificate-based client authentication in SSL). This separation of roles is what asymmetric cryptography is about.
In your proposal, the server is both certification authority and verifier, so the separation is pointless. Cryptographically speaking, certificates add nothing to the security model, that you did not already get from a classical symmetric authentication, i.e. a random cookie given to the client during registration, and simply sent back afterwards.
However, for practical reasons, some banks go to the trouble of issuing certificates to their customers, because usual Web browsers tend to be much better at protecting private keys than cookie values. For a start, cookies are normally stored in cleartext as files somewhere on the user computer. Also, customer certificates may be used, at some future point, to have them sign documents with non-repudiation (e.g. bank orders, such that the bank can prove later on to a third party, such as a litigation judge, that the customer really issued the order); getting the customer to store and use a certificate requires a bit of training, and some banks feel that this is a useful investment for a future deployment of a signature solution.
