I like it. I figure that the QT client must have something similar in it, as it is able to present a confirmation dialog to the user before sending that shows the fee, and the send can be cancelled at that point. So it would seem that the code exists, and just needs to be exposed in the RPC api. Your proposal seems good to me.
Well, he does have CoolPages. But I'm gonna stop there, I said I was out of this argument :p
UPDATE : Regarding the fee calculation, the following RPC calls would be nice to have :
preparetransaction(sendAddress, amount, maxFee, lockInputs)
Prepares a transaction by using the following parameters :
sendAddress : b58 encoded destination address
amount : amount of coins to send.
maxFee : maximum fees the sender is willing to pay, or -1 to specify no limit.
lockInputs : whether the inputs used to prepare the transaction should be locked. This feature is mostly for wallets with high volumes of outgoing transactions, to ensure coins stay available until the
Return value : a JSON object { hex: "signed tx raw data", fee: "0.1" }, where hex contains the signed raw data for the transaction , ready to be passed to sendrawtransaction. fee contains the fee amount that has been included in the transaction when this fee does not exceed the user specified limit. If the required fee exceeds the user specified limit when he passed a positive value to maxFee, an error object is returned with a message stating the required transaction fees exceed the user's limit.
canceltransaction(hex)
Cancels a prepared transaction by using the following parameters :
hex : raw data of a previously prepared transaction.
Return value : boolean indicating success or not.
This call would be required in case preparetransaction was called with lockInputs = true.
If the user is satisfied with the prepared transaction and the applied fees, he can then submit the hex data to sendrawtransaction to broadcast his transaction on the network and get the transaction's ID.