Optionally, later you move to a custom memory-backed backbuffer allocated using CreateDIBSection(), so you can just set each pixel using the CPU as a uint32_t RGBA value. That allows you to go wild, you can proceed to write your own 3D game engine with nothing to distract you - it's you, the CPU, and the backbuffer memory. (It will be running at software rasterizer speeds, of course - but it should be easy to get very good performance at say 640x480).
It shouldn't take you more than a few hours to maybe 2 days to get the ball rolling, depending on your prerequisites. I initially found the Win32 API to be a bit arcane with its overboarding use of preprocessor and of typedef'ed types (even "pointer-to" typedefs like LPCSTR instead of simply "const char *"). But beyond these superficialities, I find that large parts of it are fairly well designed, and anyway the code to interface with the OS can all be kept in a central place.
Once you're a bit accustomed to these things, maybe afterwards you'll look back and wonder how you could put up with the piles of abstractions all these fluff libraries put on top. And personally, while this approach is not suited to quickly hack up a GUI in a day, I find it's a great feeling to be in control of everything, and this will show in the quality of the product as well.