UART Transmit issue in VHDL
the process to go idle whenever the carriage return (CARR_RET) in the message buffer is detected.


If you look at the above carefully your should notice that your specification is already wrong. The correct specification would be:
"the process to go idle after the carriage return (CARR_RET) has been sent." 

That means detect a CR has been loaded in the the transmitter and the transmitter has sent it. 

Next you try to solve this by adapting your existing logic. I would not do that. Instead I would keep that functionality separated from the other functions and add a small FSM to specifically deal with the issue:  


Idle state, goto 2 if a CR has been loaded in the
transmit register.
Goto 3 if the transmit register has started shifting out.
Goto 4 if the transmitter finishes. set line to not-ready.
Wait for a 'goto idle' signal, set line to ready.


In state 4 you need some condition on which the FSM is reset again, but you did not talk about that part of the protocol in your question.



Your  comment:  


  Is there any particular reason why you wouldn't adapt the existing logic?


is a good one so I'll answer it here:

Experience has shown me code is easier to understand, debug and maintain if you keep functionality separated. In fact you are doing that already as you have a separate process for the READY.
Now all you need to do is make that process a bit more intelligent by keeping better track of what is happening, which is like the sort of FSM I suggested. 


  Also, the FSM would be reset when the message buffer has a new message loaded into it


That is not the right way. A reset is there to set an initial state. Sending the next character should not require you to use the reset. I consider that sloppy and the easy-way out. 

In a real chip the reset goes everywhere on start-up and now you are going to have to add some 'or' functionality to reset the block also when a character needs to be sent. 
Your company's Design-For-Test engineer will give you a firm talk-to for that as it will play havoc with his scan-chains. 

Furthermore you reset is asynchronous which can cause glitches in all logic down the chain. If you really want to use a reset use at least a synchronous one.