You should not need to change the signature/name of the DLL that you link to when calling in to USER32.DLL functions.
Despite the naming convention, on a 64-bit Windows machine, the USER32.DLL file that sits in [Windows]\System32 is actually a 64-bit DLL. The real 32-bit version of USER32.DLL actually sits in a folder called [Windows]\SysWow64.
Please see this question for further info.
The one thing you'll probably need to be most careful of is the datatypes that you pass in as parameters to the various Windows API functions. For example, the "SendMessage" function within USER32.DLL has a specific requirement with at least one of it's parameters (according to the page on P/Invoke).
It's signature is:
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);
and notes 2 & 3 below clearly state:
2) NEVER use "int" or "integer" as
lParam. Your code WILL crash on 64-bit
windows. ONLY use IntPtr, a "ref"
structure, or an "out" structure.
3) NEVER use "bool", "int", or
"integer" as the return value. Your
core WILL crash on 64-bit windows.
ONLY use IntPtr. It's not safe to use
bool - pInvoke cannot marshal an
IntPtr to a boolean.
This "caveat" appears to be specific to this particular function (SendMessage), although it's something I would pay particular attention to when calling into any Windows API functions.