1. Is it a reasonable solution?
That's hard to say; for a transport protocol - which is what you are designing - you have hardly described anything at all. Yes, a counter can be used to make messages unique as to avoid replay attacks and introduce randomness when combined with the AES key.
2. Are there any possible security risks?
Plenty, but with the minimal description - without even a mode of operation or message description, use case, threat model etc. - it is hard to tell which ones would be applicable.
3. Since the plain text will not repeat itself, should I still use an IV? or can I omit it?
That depends on the mode. If your messages are only one block then you could use ECB mode, which does not require an IV . Otherwise it depends on the mode of operation.
For instance, encrypting a counter in the plaintext message with e.g. AES-CTR will not result in randomizing your ciphertext; in that case you need to use an IV. For AES-CTR, every bit of ciphertext doesn't depend on any of the other bits, so you cannot rely on the message randomizing the ciphertext itself. This is also the case for most authenticated modes of operation (e.g. GCM) as they internally rely on AES-CTR mode for confidentiality.
However, if you put the counter / randomness in the first block of plaintext for AES-CBC then you would be fine, and you could use an all-zero IV.
4. Should I use a MAC, or is the counter is a sufficient authentication?
No, a counter is not authentication. You need either a MAC or an authenticated mode of operation (assuming you require message authentication, which is commonly the case).
After the edit: sure you can use ECB mode (which is just the application of the block cipher for a single block) to encrypt a plaintext block that includes a counter.
It depends on the size of the counter if you could see the result as authenticated. If the counter is 64 bit then you get 64 bits of security, which could be enough given that you require a new counter each time. If the counter is smaller then I'd certainly make sure that you only allow one (or a few) ciphertext messages.
Furthermore, you should never ever repeat the counter for the same key. Not on restarts, for instance.
Looking at your level of questioning, you're not yet ready to create your own transport protocol. You could have a look at e.g. TLS. There is also a version for packet encryption called DTLS. Or any one of the lightweight transport protocols used for embedded applications.