There was some discussion about earlier on IRC.
Right now, message signing is a very low-level function. It has very interesting applications, but in its current form, you're not going to use it unless someone tells you to, or know what it does.
The one point where it makes sense, and the only way I see it being intuitive, easy and useful, is as part of a payment protocol. By which I mean this: an address is a URL or something e-mail like, and the client connects and requests payment information (such as the public key/script to send to, the amount, maybe a message, maybe an order id), the client constructs a transaction and sends it directly to receiver or his payment processor. When such an address is selected, the client could enable a text input field for a message to attach to it, and it would travel together with the transaction directly to the one who cares, with a signature that it comes from the payer.
At that point, it absolutely should be a first-class feature. But right now, it's obscure and unclear.
I think if this could be added to the URI spec, it would be useful
and easy to use. For instance:
(1) I want to buy a widget, so I got to the widget merchant website
(2) Enter in my shipping address and details
(3) Click on the link to pay -- client pops up asking if the payment details are correct
(4) Merchant site detects the payment and gives a link: "Please confirm payment details"
(5) Client pops up saying: "Please confirm shipping address for your order: Name: ... Address: ... Email: ..."
(6) User clicks "sign" and sends it back
It would be even better if the message signing URI included an IP address so that the client would just dump the signed message where it needs to go after signing and the user doesn't have to do anything other than click "Sign".
In this particular use-case, the user doesn't even need to realize they're "signing a message." They are just confirming transaction details. If it's handled under-the-hood like this, merchants can get the benefit of authenticated messages without much inconvenience to the user.