Ok. Here's what I found.
I even installed qpop myself to be sure I wouldn't be taken out into the field, etc, etc :-]
The sendmail part will be allright. There's no doubt about that. (Keep yer eyes on the money) Running as a (severely) underprivileged user will lose you some functionality, but if all apps run by that user are not $UID == 0, the only user (say in case of BO (not body odour, heh)) they will end up as will be the $UID of that underprivileged user.
Now unfortunately Qpop will not have this; a user sends mail off to another user. This will have sendmail either defer to mqueue (say due to host unreachable), or gets mailed by the local mailer (LDA, say procmail) to a local user's spool (mail) or is sent right away by sendmail.
No probs to this point.

Now the user accesses pine to read local mail, this is loaded from the mailspool (/var/spool/mail/$UID, with $UID=$UID and $GID=mail). No problem here.

Now the user accesses :110 to read mail.
When Popper is started from (x)inetd (as root) it will (fork() and) change $UID and $GID to the connecting user to read mail.
But when popper is started by an underprivileged user, presto, there's no way popper *can* change $UID and $GID to the users' mailspool.
RTFM'ing Qpop's docs I came to the conclusion this pop3 server does not have any way to safely work with an $UID != 0, I can't find any option so it would only have to change $GID and work with that.

/* Alas, thus endeth this thread in the valley of Death, after exactly 9 days worth of 'em...
Was definately fun working with you on this one, even tho we didn't accomplish all goals.

Cheers, unSpawn
*/