If you use g.711, that's basically the same codec used when your calls pass over a T1 or other digital phone service. Which should be fine.
You're adding latency though, because g.711 over RTP is generally sending 20 ms bursts of data, so now you've got that to deal with.
I don't know if the cisco ata's short circuit the audio path if both ends of the call are on the same gateway, if so that would eliminate or significantly reduce the latency penalty.
It would still be encoded, assuming your (analogue) POTS call traversed more than one exchange then it would have been coded to g.711 (ulaw or alaw) for that inter-exchange. Although (from memory) that would be 10ms packets.
T1 time slots are 8-bits, samples are sent individually, with no packetization delay. There may be some delay between sampling and the time slot, and in a buffer when calls are connected between T1s and the time slots don't need to be matched up.
If you were calling into an x2/kflex/v.90/v.92 modem bank, that was hosted on a T1 (or larger), and v.92 could get 33.6 up, 56k (or so) down. It should be possible to recreate that with VoIP, but I don't know that anyone is that dedicated... anyway for end user modem to end user modem, 33.6 is the limit.
I recently tried this for making a YT video using an ATA with a USR Courier dialing into a ISP's POP in San Jose. V.92 flat out didn't work for me, but V.90 did. Surprisingly I was able get 50-53k downstream carrier rates, upstream was pretty lousy at 14.4-16.8k. The calls only lasted a couple of minutes before they were unable to renegotiate. 28.8k was much more reliable.
You're adding latency though, because g.711 over RTP is generally sending 20 ms bursts of data, so now you've got that to deal with.
I don't know if the cisco ata's short circuit the audio path if both ends of the call are on the same gateway, if so that would eliminate or significantly reduce the latency penalty.