EAC seems to be somewhat of a RAM hog and a little unstable on my xp box.

If I remember the EAC mailinglist correctly, there are known instabilities under XP in certain situations. IIRC, they can get worked around by installing ASAPI and using that instead of the built-in ASPI or Win2K/XP native interface.

i think that CDex with lame 3.88 with VBR0 - min bitrate 192 / max 320 will be good.
do you think this will be equivalent to the EAC / lame 3.9 combo?

I can't comment much on this either. VBR0 with a min. of 192 sounds pretty high for my taste. VBR0 with a minimum of 128 should be good in any situation. Leave the max at the highest possible value (was ist 320k or 384k?) though, to encode with the best possible representation. I can't say anything about the lame 3.88/3.9 differences though.

the EAC with lame encoding concurrently is very slow compared to CDex.
Well, this is probably because EAC makes sure that it always does _exact_ audio copies, just like its name says. CDex is ripping a disc once, EAC usually rips it twice to make sure he got the right result. Make sure your drive is set up correctly. If your drive does not cache audio data (EAC can test this for you), make sure the relevant checkmark is not set in the drive setup, because audio caching slows down EAC significantly. Also, if your drive supports C2 error detection, make sure the relevant checkmark is set. Again, EAC can test this for you, though this test is tricky: You need a scratched disc to do this test, so that read errors occure, but it must not be scratched so badly that you can't read it at all. Third one is "accurate stream". This one should be set if you are sure your drive supports it (most modern drives do), because if your drive does accurate streaming, EAC can skip jitter correction. So, to sum this all up, here are the most secure settings for the drive options, sorted by the impact they have on EAC ripping speed:
Drive caches audio: Unset only if you are sure your drive does NOT cache audio.
Supports C2 error correction: Set only if you are sure your drive supports it.
Does accurate stream: Set only if you are sure your drive supports it.
If you do not want to make sure to get perfect rips, but want to rip as fast as possible, just set the extraction method to fast mode or burst mode. The former does jitter correction if needed, the later doesn't IIRC.

I also like the way CDex creates a folder for the artist, album, and puts the appropriate songs in along with a playlist.

EAC can create folders based of artist, album, year and any other id3 information it supports. Under EAC options, Filename, construction of SAVE filenames , just set a filename like
%D\%C\%N - %A - %T
To create directories/files like
\Various Artists\Rock Symphonies\01 - Some Artist - Some Title.mp3, or
\Elton John\Best of\02 - Elton John - Some Title.mp3
Note the backslashes between the different tags to delimit directories.
It is also able to create .m3u playlists, at least one for each ripping process (so usually a whole CD).
Regarding the question about extraneous files: All non-audio files are ignored by emplode and AFAIK also by jEmplode. With one exception: .m3u playlists are not ignored by default, IIRC. But this is settable in the options, so they can also be ignored. Note however that jEmplode has a very powerful feature: It supports nested .m3u playlists, so you can "include" CD playlist files in an artist playlist. This way, you can mimic the complete playlist structure of your empeg by creating the right m3u playlists. To "include" a sub-playlist, just specify its pathname in the "parent" playlist, just like you would normally specify an audio filename. Like this:

test1.wav

test2.mp3

test3\test3.m3u

test4.mp3

This playlist would play the test1.wav, followed by test2.mp3, followed by whatever the test3\test3.m3u playlist specifies, followed by test4.mp3.

cu,
sven