I have similar desires to yours. I solved it using a system-level modifier-key re-bind.

(Of course, this is a mess; but I find it worth it to maintain my MacVim-trained hybrid of OS-wide controls (save, new, copy, paste) within command-line vims.)

Here's how I did it:

1. Install Karabiner, which is a very, very powerful program (and an essential part of any poweruser's / programmer's OS X installation, IMHO)

2. Enable “Command_L to Control_L (only in Terminal)”:

3. Map ⌃-prefixed controls matching whichever MacVim commands you're most used-to in command-line vim. For instance, to support ⌘S,

   noremap  <silent> <C-S>    :update<CR>
   vnoremap <silent> <C-S>    <C-C>:update<CR>
   inoremap <silent> <C-S>    <C-O>:update<CR>
   

4. Restore expected ⌘-sequences for Terminal.app itself, by special-casing them in System Preferences. For instance, if you want ⌘N to still control Terminal tabs, instead of mapping it to vim files, try:

   Now, anything you don't add in this list, will be passed through verbatim to command-line vim (and, of course, any other command-line program you use.)

Caveats

This approach has several further subtle downsides, that I want to hilight for anyone considering taking it (as I do):

• ⌘␣ will no longer map to the system-wide Spotlight. (I've an open issue on Karabiner, and will come back here once I have a stopgap solution.)
• For reasons I can't ascertain, even with the ⌃W exclusions set up in System Preferences, the tab-closing behaviour of Terminal.app changes with this setup: ⌘W will close individual tabs in a window; but if the current tab is the last tab, it will not close the window. Instead, it has no effect. I've had to re-train myself to use ⇧⌘W to close the window if there's only one tab left.
• If you've trained yourself to use ⌃V in MacVim to do block-wise selection, then you'll have to re-train yourself to use the alternative, ⌃Q (or, now, ⌘Q). Additionally, you'll have to add stty -ixon in your shell's startup-script, as ⌃Q is consumed by default to preform an archaic shell-control function (one with no modern usage.)

Alternative ⌘W behaviour

In addition to the above, I decided to further override ⌘W as a universal ‘close this’ key, applicable to multiple applications.

Instead of mapping ⌘W to ‘Close Tab,’ as above; I personally map that to ⇧⌘W (to retain “immediately close this tab” semantics.) Then, in any given program, I map ⌃W to some sort of close-save-quit functionality.

For instance, in my .vimrc:

noremap  <C-W>    :confirm quit<CR>
vnoremap <C-W>    <C-C>:confirm quit<CR>
inoremap <C-W>    <C-O>:confirm quit<CR>

… or my .zshrc:

function close_tab { exit }
zle -N close_tab_widget close_tab
bindkey           '' close_tab_widget
bindkey -M vicmd  '' close_tab_widget

With those two snippets in place, and your Terminal configured to ‘Close if shell exits cleanly,’ a series of ⌘Ws will first quit vim, and then close the shell entirely.

In addition, now additional on-exit functionality of programs can be preserved: for instance, vim will ask before quitting if files are unsaved (just like MacVim); and zsh will ask before quitting if there are background jobs.

Postscript: Not directly related to your question; but you should also check out ‘Ubiquitous Vim Mode’ in Karabiner. It's “a bit much” for me to use everyday, but it's a very cool idea, and surprisingly-well implemented.

In general, Mac applications that are expecting text input from the keyboard do not handle C-S combinations or C-digit combinations. Programs that work with control-shift combos (like anything running under X11) do so by handling key events as events, not character input. This is how they can differentiate between Tab and Ctrl-i, which both generate the same ASCII character. (You can read in detail how Lion (really Cocoa) handles key events if you really want to know.)

Historically (back in the Teletype days), there were only uppercase letters on the keyboard, and there were no caret (^) or underscore (_) characters on the keyboard (instead there were up-arrow and back-arrow). The shift key worked by toggling the 16's bit and the control key worked by zeroing the 64's bit of the 7-bit ASCII codes the keyboard produced.

What this means is that the control key had no effect for the 32 characters on the keyboard that already had their 64's bit set to zero (most of the non-alphabetic characters, including digits), and since the teletype was purposefully limited to upper-case letters only, the shift key had no effect on most of the alphabetic characters (and where it did have an effect, it produced a special character like @).

Additional weirdness was added in the migration to supporting lower-case text, as the control key combos were all typed without using the shift key but now the letter typed without using the shift key had changed, so the decision was to map control-lower-case to what had been control-upper-case. But then what do you do with control-shift?

For a while the problem was handled by having the control key also zero out the 32's bit, which is what differentiated lower case letters from upper case letters. But eventually ASCII was replaced with Unicode and those kinds of duplicate key assignments were too much of a waste of keyboard space to be allowed to continue, so they got different mappings, and on the standard Mac US keyboard most C-S combos are unassigned.

So what you have run into is the legacy support for keyboard input running back to Teletype days. The characters Terminal (and other OS X apps) do not support are characters you could not type on the Teletype keyboard. As evidence of this, note that C-S-2 (C-@), C-S-6 (C-^), and C-S-- (C-_) all work, because those keys have been re-mapped since the ASR-33, where S-2 was " (and @ was S-P), S-6 was &, and S-- was =, but in general control-shift combos do not produce characters of any kind.