I must preface this by saying: My in-depth analysis isn't yet finished. But with what I've observed so far...

1. In all cases I've observed thus far,** this is true: It seems the Wii U renders TV frames at 1280x720.*

*: 2. To talk a little more in-depth on this... The way the Wii U works, in memory it has a framebuffer for the frame that is (going to be) displayed on the TV, and it has a framebuffer for the Gamepad (DRC). By far the most common case is that the DRC framebuffer is 854x480 and the TV framebuffer is 1280x720.
For each of the two screens, that framebuffer gets passed to whatever part of the OS or hardware is responsible*** and that automatically takes care of upscaling or downscaling the image if necessary before encoding it into whatever format and sending it down the wire. (for the gamepad it gets encoded as an h264 video stream, for the TV it's whatever protocol used for HDMI or Component or Composite or whatever, the details on that conversion aren't especially important to what I'm talking about here...)

3. Example cases:
- For example 1, let's say the user has configured the Wii U to output to the TV via HDMI at 1080p. In all cases,** the game is rendered to the TV framebuffer which is 1280x720, then the system basically makes its own copy of that framebuffer and upscales it to 1920x1080, then the 1920x1080 version is what's sent down the wire via HDMI.
- For example 2, let's say the user has configured the Wii U to output to the TV via Composite video at 480i. Same as above, the game is rendered to the TV framebuffer which is 1280x720. Then the system takes a copy of that and downscales it to 480p/480i (specifically 720x480, don't ask...) then the 480p/480i version is what's sent down the wire. (I'd imagine the 480p version is sent to a DAC chip which converts it to 480i by removing half the scanlines, this detail's not important.)

**: 4. The TV framebuffer is 1280x720 in all non-hacked cases I've observed thus far. I say "all cases" instead of "all non-hacked cases" because the only exception I know of is SwipSwapMe, a homebrew plugin for Aroma custom firmware.
There's an OS function used by the application currently running in the foreground to send each of the screen framebuffers to be output to the TV and Gamepad. The SwipSwapMe plugin hooks and intercepts that function every time it's called, and allows the user to redirect the TV framebuffer to be output on the Gamepad and/or redirect the Gamepad framebuffer to be output on the TV.
SwipSwapMe doesn't do any image upscaling or downscaling itself; when SwipSwapMe sends the Gamepad framebuffer to be output on the TV, SwipSwapMe is sending a framebuffer of resolution 854x480.

***: footnote: I don't know the exact details about this. To clarify:
- Possibility 1 is that the code running on the main CPU basically passes the framebuffer at whatever arbitrary resolution to the GPU/DSP/whatever, and the GPU/DSP/whatever automatically takes care of resizing the image.
- Possibility 2 is that the code of the OS (specifically one of the system background processes running on the PowerPC) that I've mainly been looking at, well, maybe it's actually not interfacing with the AV output as directly as I think it is according to Possibility 1. And when I'm passing a framebuffer that's some arbitrary given resolution, I'm not giving it directly to the GPU/DSP/whatever, I'm actually giving it to some other function within the OS running on the PowerPC (or perhaps a function running on the ARM coprocessor) and THAT is the thing that automatically takes care of resizing the image before sending it to the GPU/DSP/whatever (and by extension sending it down the wire).
- Regardless of whether the truth is Possibility 1, or Possibility 2, or something in-between, or something else entirely (if my working theory is entirely off the mark)... My working theory is basically operating under the assumption that this image resizing process (a.) happens automatically and (b.) isn't directly within the control of whatever application is currently running in the foreground.

additional footnote: i basically only have reverse-engineered/decompiled binaries and existing documentation of the OS APIs to look at for information. exactly 0 of my knowledge here is derived from leaked source code or confidential internal documents. and for that matter, no Wii U OS source code or internal documents have leaked that are relevant to this, so i couldn't get information from those even if i wanted to.