Authentication based on asymmetric keys is already supported by SSL under the name "client certificate". Indeed, a signature is involved. If you want to use a client asymmetric key, you are encouraged to use this SSL feature which is already implemented by SSL libraries.
Using an asymmetric key for authentication is useful when the identity of the client is asserted by a third party: an entity, distinct from the server, makes the initial identification (aka "certification" with certificates), and the server relies on this identification. This is a separation of roles which may or may not be useful in your context. Another way of viewing it is the following: when the client connects to the server, in a login+password scenario, then the client sends its password to the server. Therefore the server learns the password. A consequence is that the client must not use the same password if it is connecting to several servers which do not trust each other. With a client certificate, the client can use the same certificate with every server.
If you do not need the extra functionalities of certificates, then a login+password is fine. Actually, if the client works in an automatic fashion without a user entry, then the "password" is stored somewhere in the client, not typed by a human. Therefore, that password can be a bunch of random bytes, which will be much more robust against exhaustive search than a human-remembered password. Under these conditions, you may want to use SSL/TLS-PSK which will build on this "pre-shared key" and avoid the need for any certificate, neither client or server.
Similarly, if the password is indeed typed or remembered by a human, consider TLS-SRP which also needs no client or server certificate, and, moreover, tolerates passwords of limited entropy.
