From a simple utility perspective, yes, you can use Keychain. I strongly encourage you to read the entire security(1)
man page which has additional caveats.
You can enter the password using the Keychain program or via the command-line:
# WARNING: exposes password in ps(1), history(1), etc.
$ security add-internet-password -a $USER -s pop3.example.com -w 'Mellon!'
You can extract this with:
# Note: by default, first use will prompt
$ security find-internet-password -s pop3.example.com -a $USER -g
If you Always Allow, security(1)
will be able to pull these credentials without further prompts. This may be a risk on your system. You could opt to have this always prompt for your password before launching, however.
Finally, using this, you can wrap your fetchmail
call with a springboard script that sets the password to be used.
user=$USER
server=pop3.example.com
# WARNING: insecure tmpfile creation and usage
# As [DAM][1] mentions, see mkstemp(3)
tmpfile=/tmp/fetchmailrc.$$
password=$(security find-internet-password -s $server -a $USER -g 2>&1 \
| perl -ne '/password: "(\S*)"/ and print $1')
# create temporary fetchmailrc and pass to fetchmail, etc...
cat <<EoF > $tmpfile
poll $server with proto POP3 and options no dns
user $user with pass '$password' is $user here
options keep mda '/usr/bin/procmail -d %T'
EoF
fetchmail -d -f $tmpfile
rm -f $tmpfile
While this does achieve your stated goal of not having obvious files laying around with passwords, I did note the security risks still present with this configuration, which you should consider.