I do appreciate all of the help, but the issue is that the keyboard isn't being picked up as a controller, so I can't get to the step that allows me to configure the ACT settings/assignments.  Same thing is true if I try to use a generic surface, it allows one to be added, but upon clicking apply when selecting the device for in/out, it blanks out the fields.
 
Here's a video that shows the problem, I think it might be the OP who posted this.

 
There seems to be an issue with Sonar X3 running in 64 bit.  The odd thing, is if I try to run it in 32 bit, it shows it as a controller, but rejects it if I try to run the prefs->devices saying there's an unexpected error (followed by a 50/50 chance of a BSOD in a minute, "bad header pool".
 
 

BSOD is 99.99% driver related. It looks like once SONAR tries to use the driver, it crashes.
 
You have mentioned you can use the board with VST. Is DimPro 64bit runs fine with it?

I don't have it, but I've had no issues at least getting any VST's to work, both 32 and 64 bit.  Rapture works fine.  I should mention that when I say fine, I mean will make noise.  None of the controls are functional unless I midi-learn for things like rapture - beyond pitch bend, modulation, volume, pan.  In CSC, the knobs do work, but I still have no communication as far as transport tools go, or being able to assign sliders into the background functions in the main interface.  It appears that something is just blocking it from accepting it as a valid control device, because the midi data is being accessed by VST's.  If there was a way to force the config (by manually editing an .ini file) I'm pretty sure it'd be fine if it didn't perform the check when started up - if there's a command line parameter to skip that.
 
Lots of reasons for BSODs, but usually it's something low level.  A bad pool header usually has to do with memory allocation, but can certainly be caused by bad driver communication.  I've removed and reinstalled both the basic Microsoft drivers and the M-Audio drivers, no change.

Have you already tried another USB port and cable? I also hope you do not have a hub in between.
What you describe can be hardware flickering: the board is periodically unavailable for communication, some programs can tolerate that, other not.
 
"Not perfect" assignments of controls is completely different question. That is "normal".

yup, yup, nope
communication's stable, that's not the issue.  resolved the issue in 32 bit mode now, but i still can't get the 64 bit to accept it as a controller, so I can't even get to the point of assigning controls.