OK, this is why users should be disabled, rather than removed. There are built-in options to passwd for that sort of thing (and settings exist in every centralized-user-management software that I know of for it).
But you're not here to get yelled at.
Do the user's files still exist, or were those removed with the account? Screen uses the lock files to reconnect, and if they're gone, I'm honestly not sure how to reclaim the sessions.
Try Keiran's suggestion of recreating the UID if possible. Sometimes it isn't feasible, especially in a centralized authentication where the IDs are hashed from the other user information, but if you can, that would be swell.
Assuming you can't, you need to find a way to take over the terminal. I'm going to guess that TTYSnoop isn't configured on your system already. In that case, it's going to get hairy.
Assuming that your screen sessions issue you a pts/# terminal like mine do, there may (MAY) be a chance. pt stands for pseudoterminal, and it's sort of client/server based. There are the pt slaves, which is the terminal that you type with, and there is the ptmaster, that receives the input. There are many slaves (/dev/pts/*) to one pt master (/dev/ptmx). From the man page to ptmx:
Before opening the pseudo-terminal slave, you must pass the master’s
file descriptor to grantpt(3) and unlockpt(3).
Once both the pseudo-terminal master and slave are open, the slave pro‐
vides processes with an interface that is identical to that of a real
It may (may!) be possible to assume the identity of the terminals that you want to assume (oh hell, might as well just say hijack at this point) using a custom written program that conveniently overlooks certain safety measures, like the pre-existence of the file descriptors you want.
It's probably much less work at this point just to concede defeat and lose the data.