Can I determine if my computer has a key logger installed? – YES!!!

Detecting keyloggers is as simple as looking in the right place (which may or may not be simple depending on your viewpoint). The problem is knowing what to look for and where. What follows is a non-exhaustive few things you could do to check for keylogging modules.
Firstly, the obvious easy way to build a keylogger is to use DLL Injection which can be achieved a number of ways. Most of these will result in a DLL showing up as mapped to the process’s address space. Take a look at this picture:

What is the topmost entry in that list? It’s a pyd, or python extension, file. I’ve been messing with python-implemented COM servers and as a result, the DLL is loaded into Windows Explorer’s address space.
DLL Injection of the keylogging variety will load its DLL into all of the target address spaces – can’t capture everything if you don’t. So one thing to look out for would be strange DLLs you cannot attribute to products whose purpose you know. They’ll show up in this list for all processes.
Of the techniques described on wikipedia, the only one that I’ve not seen is the CreateRemoteThread variety – I’m uncertain if the outcome would be to attach a thread to the image or execute a thread with a name DllMain. Thanks to process explorer, we can still see what threads are executing what:

Awesome, right? Well, they could well be named to coincide with the obvious user32.dll or some such. There’s a number of experiments we could perform to work out if that’s the case, if we so wanted. These are left as an exercise to the reader (don’t you just hate it when people say that!).
So that covers user-mode-obvious-keylogger-mode. There are some less obvious places a keylogger could be embedded (but they’d unlikely be global ones). However, things get really exciting when you start talking about kernel level hooks. There’s an excellent article by Mark R and Bryce Cogswell on this topic, although it needs updating with the following caveat:

• 64-bit Windows kernels have a kernel-patch protection mechanism that periodically checks key points in the kernel for modification and shuts the system down if they’re detected.

So, if you’re running 32-bit windows, you could still have some form of kernel level hooking installed and working; if you’re using 64-bit it is much less likely – given KPP has been bypassed before and is constantly changing, I would bet on you being free of kernel hooks on x64 as windows updates would crash the monitoring product system periodically. Software just doesn’t sell on that basis.
What can you do versus a 32-bit hook? Lots of things:

• Examine the drivers folder for entries that look suspicious/cannot be attributed.
• Do the same thing, but offline, so that the driver can’t prevent you from looking.
• Configure a debug boot entry with bcdedit (bcdedit /copy {current} /d "Windows in debug mode", bcdedit /debug {id} ON after appropriate bcdedit /dbgsettings), hook up a firewire cable (really. Don’t use serial. I discovered this using serial cables – firewire’s much faster). Then, on your source machine, start kd and set a break point on module loading, then step through all the modules that load, making a note of them. Not much a driver can do to hide itself from you before its started. You might even proceed to examine it from here (g to continue, ctrl+c breaks at any point).

Of course, caveats here are that no windows executables have been patched directly, or some such malfeasance that is beyond our ability to trivially detect.
That’s directly looking at the system, but is no means a complete solution. If you believe the logging software is phoning home, a transparent proxy might help you identify where – i.e. you might be dialled in to vpn.mycompany.com but you might also see connections to monitorserver.mycompany.com.
As you can no doubt tell, a lot of the techniques available to you depend on two things:

• Your pre-existing familiarity with your OS, or ability to quickly become familiar with what is out of place and
• The ability and resource of the author to hide/disguise their modifications from you.

Short answer: there’s no foolproof way to detect anything of the sort; there are however some places you can start looking for evidence.