Is this occurring when you run Tlist, or when reconnecting to a previously opened session?
If it's the latter (and your window size varies), it may be because of the options screen was launched with. Try launching screen with these options "-aADR". "-a" and "-A" will force screen to redraw upon reconnection.
Parsing of ~/.Xresources is done when the X11 server is started, as part of the X11 session init scripts. If you edit ~/.Xresources then you need to use xrdb(1) to load in the new file to tell the running X11 server about the changes.
BEWARE that xrdb(1) will, by default, replace the current resources instead of overwriting them and read from stdin is the default, so don't invoke it with no parameters! So you want to use
xrdb -merge ~/.Xresources
to load the changed file in. You can use
xrdb -query
to see what's already loaded.
For the Mac, I don't know what, where or when, might be looking at ~/.Xresources; because the X11 stuff is a program run to use the display, rather than the master of everything graphical, it might be rather minimal and not doing so by default. xrdb -query will help.
One thing that might help is to instead set XAPPLRESDIR as an exported shell variable; there's some knob somewhere in MacOS to set environment variables as a session thing, visible to all programs without hitting the user shell, but I forget where (found it when setting up the SSH Keychain once). XAPPLRESDIR is an env variable variable to point to a user's own overrides of application resources. It's value should be a directory ($HOME/share/xapps/ for instance). Every X11 application linked against the X Intrinsics library (libXt) will, at X11 init time, look in that directory for files matching the application class name. This way, you don't need to worry about loading resources, etc; edit the app file, start the program.
So resources for xterm go into a file XTerm, etc; to find out the class of an arbitrary program, you might use xprop(1) with no arguments, click in the target window while the pointer is a cross-hair and then look at stdout from xprop for the WM_CLASS property. For some older tools like xterm you can also use editres(1) to be able to interactively view the widgets of a running X application via remote inspection; there's a Get Tree menu item, to let you click on the target app and another menu item to show the class names.
Myself, my ~/share/xapps/XTerm file sets the menu background colour to a hideous yellow; that way, when I control-<left|middle|right>-click in an XTerm I immediately know if something is wrong and my resources weren't loaded.
#ifdef COLOR XTerm.SimpleMenu*background: yellow #endif