Do I need to use AE/AEAD in my particular scenario? Or is it redundant? This is my scenario:


A small structured text message (1-2kB) is to be sent over an insecure channel. 
Everything except for the header portion (which contains a title, timestamp, category and tags) is confidential. 
The message as a whole has integrity and non-repudiation as additional requirements.


This is how I intend to go about it after having done some crypto-related research:


Encrypt the message with AES-CBC/OFB/CTR (key is pre-shared). The IV is added to the front of the ciphertext.
Add the non-confidential portions to the output from (1).
Make a digest-hash(SHA512 or RIPEMD160) of the output from (2) and encrypt it with the message author's private key (public key is pre-shared). Add that to the output from (2).
Send it over the insecure channel.

&lt;---IV---&gt;&lt;---AES Ciphertext---&gt;&lt;---Header---&gt;&lt;---Signature---&gt; 



Question:

I know that MAC algorithms and digest algorithms were designed for different purposes, but in this case, my digest is not merely slapped onto the payload, it is asymmetrically encrypted.

So, would the choice of AES-GCM/CCM/EAX have added any additional security? 
Does my scheme have any obvious vulnerability that I overlooked?

Any help is greatly appreciated.

EDITS:  


Fixed a typo. OBC $\rightarrow$ OFB.
I did not realize that the hashing algorithms are already built into all the major signing algorithms; I thought you had to do it yourself. Thanks for clearing that up.


NOTE: I would have chosen Ricky D.'s advice, but comments cannot be chosen as answers.
In general signature creation contains the hashing part within the algorithm. A signature algorithm may also contain a padding mechanism such as PKCS#1 v1.5 or PSS for RSA. Finally it contains a one-way trap door function (modular exponentiation within RSA). Encryption has other requirements, and uses a different padding mechanism.

Basically you are encrypting a plaintext, and signing all the data including IV within the message. I don't see the need for either a MAC or an authenticated cipher; the signature is perfectly fine as authentication tag. That does not mean that your current scheme does not have weaknesses:


it does not provide forward secrecy (i.e. if your secret key is compromised, all the messages can be decrypted)
you have to keep both a private key and share a secret key
asymmetric operations are expensive (with regards to CPU) and you need a private and public key operation per message
no signer anonymity (eavesdroppers can prove that messages were sent by a specific sender)
as others have pointed out, encrypt-then-sign may have vulnerabilities you should be aware of in your protocol


Those drawbacks may be resolved by a careful choice of a TLS cipher suite (if you just require transport security).

Finally you may want to think about how you are going to setup key management.