We are using SSL to make our connection between clients and backbone servers safer. Does it really make sense if also we use another encryption mechanism to encrypt transmitted data twice? For example, encrypt data by AES and then transmit data on an SSL connection?
It really depends on what you're trying to protect.
SSL only protects data in transit, and between the two set points. It doesn't protect data at rest, and it doesn't offer any guarantee that the data came from the person claimed.
So if you need to protect the data while it's stored at either of the endpoints, then encrypting it might make sense. Or if you need to provide assurances that the data came from a certain party, then signing it might make sense.
On the other hand, if you're simply decrypting the data and storing it at the endpoint, and not doing any authentication, then it wouldn't make a lot of sense to add another transportation layer.
Security often works in layers, so it's important to understand what each layer provides. SSL is merely a transport layer, and only provides assurances that the data sent wasn't intercepted along the way, or replaced with something by an attacker in the middle.
So no, in the general case it is not worth adding complexity for no actual gain in security. There are cases where certainly implementations might in fact make sense, but unless you have a very strong argument as to why it make since given your specific architecture, the general case applies.
The established SSL/TLS protocols provide the ease of all important key exchange. The additional encryption layer you have proposed will of course increase confidentiality (one of the tenets of data security). However, arriving at what key that AES can use, will be another headache, especially when you expect the key to be changing for every session.
@Xander correctly points out that adding another layer of encryption will break client browsers. But you already knew that. By adding another layer, both client and server may need modification.