I am attempting to use System Center 2012 to download, deploy, and install Windows Updates on all of the servers in my environment. I just installed and configured the Software Update Point within System Center and pointed it at my single WSUS server. The WSUS is located on the same machine as System Center. Now after adding the SUP to SCCM, I ran the "Synchronize Software Updates" from the Software Library view. I checked the logs for any errors and everything confirmed that it was set up properly and after a while I began to see my WSUS updates pour into the System Center under "All Software Updates" I created a Software Update Group and went to deploy the specific updates to a test collection. I specified it to download the content and install, reboot if necessary. Created a new share on the server and gave SCCM, and the machine full permission to the share. I then pointed the SCCM deployment to look in E:\WSUS\WSUScontent directory. When I clicked next and waited for the files to copy, I watched the new share I set up. 1 single update copies over and then I get an error that the network cannot be contacted. No other updates come over. I just retried it and pointed to Microsoft's WSUS servers instead and the content downloaded to SCCM share perfectly. 

"I then pointed the SCCM deployment to look in E:\WSUS\WSUScontent directory"

I'm completely lost here.  The WSUSConent directory contains only the metadata at this point if you let SCCM configure it, and the SUP (software update package) needs a _unique_ UNC path to download updates to.  When you deploy your SUG (software update group) it will simply grab said updates from any available Package in order to push to clients.  If you tell it during the dpeloy to use the WSUSContent dir it will fail because ... well ... there's no patches in there (not to mention thats not a UNC path)

As an additional question here, are you using a brand new WSUS instance? If not, stop everything and start over. Using an existing WSUS instance will cause you problems and is technically unsupported.

Additionally, when integrated into ConfigMgr, you should not be approving updates (or performing any administration within WSUS) and thus as mentioned by Justin, the WSUSContent does not contain the binaries needed by ConfigMgr to populate the update package(s). ConfigMgr will/should download the updates directly from Microsoft.

Yes agree with this. It's not best practice to try and get SCCM to use WSUS after WSUS has been running before SCCM existed. 

Fresh WSUS - Setup SCCM with WSUS - then the wheels should be greased.