Minimal colored write
A few things I noticed when reading through (I don't know much about how Windows.h works, so I mostly focused on stuff not related to it)


This made me laugh:

// god help us


At the same time, though, it doesn't really describe what's happening. In this case, you don't really need an explanation; it's decently obvious what's up just by reading the relevant documentation. In other cases, though, you don't explain. For example...
here:

// parhaps I should use sprintf?


Why aren't you? I'm assuming the answer is "I couldn't see a clear benefit", but then explain that in a few words. (also, *perhaps)
wOld and wNew are bad variable names. Something like oldAttributes and newAttributes would be better, since it describes what's actually going on. If that's not what's going on, you should provide better variable names so I can understand what they should be :)
Why are you making j a WORD? strlen returns a size_t; while WORD is (usually, IIRC) 16 bits, size_t can be a great deal larger. Is it unlikely that you'll be encountering strings that are longer than 2^16 characters? Yes. Is the fix so easy to implement that there's no reason not to? Also yes.
Possible UB at switch(argv[2][j + 1]). If j == strlen(argv[2]), argv[2][j + 1] accesses memory outside of argv[2] (one past the end, in fact). Depending on how, specifically, the memory is laid out, this may not crash the program. It'd be better to do for (j = 1; j &lt; len /* see below */; ++j) and use j - 1 and j where you use j and j + 1, respectively.
strlen operates by doing something roughly like this:

char *cur = your_string;
while (*cur) ++cur;
return cur - your_string;


That means that it's O(n). Performing that calculation makes your whole loop there O(n^2). If you store the length of argv[2], then compare to the stored length, you can improve the speed by a decent amount. Of course, for the number of characters you're most often dealing with, and with how simple your loop is, this doesn't matter so much, but it's a bad habit to get into.
Pretend it's six months later and you've been dealing exclusively not with text. When you see this:

argv[2][j]   = 0xa;
argv[2][j+1] = 0xd;


are you going to say "that's super clear and I know exactly what it does", or will you have to Google what the ASCII characters 0xa and 0xd are? You should put a comment there explaining it.
// How do I turn a char ** into a va_list ???

I don't think you can. Sorry.
In that same area, why are you assuming that accessing argv at argc and above will be valid, or that argv[2] will be a valid format string? You should check. Alternatively, just forget about building formatting in and let the calling code handle it (Bash, for example, can do that easily) -- it's a lot of work to try to do it yourself, for little to no benefit.
Your error codes are uninformative. Given that all you have is an integer, that's pretty much par for the course, but the least you could do is document them in the help message. 
Related: Try running this simple C program from Bash:

int main() { return -1; }


Look at its return code -- it's 255, not -1. See here for more information; the gist of it is that negative numbers might not be interpreted that way by the OS. Stick to positive ones.
What's the point of this?

if(!v) { /* nop */ } // could not reset color...


The compiler just optimizes it out anyway; you might as well replace it with

// if it fails, we don't really care


to make it blatantly obvious that it doesn't matter.
feature-request Let me put in a color's name and see the output in that color, rather than making me use the number.


That's all I saw. Someone who's more familiar with the Windows API might find more.