I started diving into Qt again last night, and a few things made me wonder how it works. For example: when the UI is designed in the Designer View, is the .ui file (an XML schema) compiled into a header/source file that contains all of the controls as if instantiated in-code?
That is correct. The uic program translates your UI-file into a header file (header only though, no source file) that you include in your code to instantiate the UI. If you have a UI called mywindow you typically have the mywindow.h and mywindow.cpp files, and you'll get a file ui_mywindow.h from the UI compiler that you include to instantiate the UI in mywindow.cpp.
The reason I ask is because the .ui file's corresponding header/source pair's class is also prototyped in the scope of the UI namespace. Then, a data member is created from that, called "ui" within the class itself. That ui data member appears to contain a pointer for each QWidget added in the Designer. For example, if I drag a QPushButton into the Designer, and name it as pushButton in its Properties Inspector, the ui member will have a ui->pushButton member pointer within it of type QPushButton. Funny thing is, I couldn't find where the "pushButton" member was declared in-code. This leads me to think that Qt Creator's Intellisense is smart enough to parse the XML file, and a class being changed behind the scenes, or at least at compile time.
When you create a project in QtCreator, you are asked for an intermediate directory for your project. For example, if your project is located in <path>/test, this intermediate build directory is usually <path>/build-test-Desktop_Qt_5_2_1_MSVC2012_OpenGL_64bit-Debug, or a variant thereof, and depends on which version (5.2.1 in this case), which compiler (MSVC2012) and Qt build options (w/ OpenGL, 64-bit, debug library) you use. You find all temporary files from, for example, the uic and the moc compiler there. This is where you find your compiled UI header files.
Then, there are, signals and slots. It sounds like they have some sort of special definition that's triggered by the Q_WIDGET macro. Also, QWidget::connect()'s 2nd and 4th parameters are of type const char*, and it's common practice to use the SIGNAL() and SLOT() macros to pass through prototypes of functions (not methods because they don't appear to be associated with any class). I understand that that I'm calling two functions that these widgets seem to have, but how does that work under-the-hood, exactly?
I won't, or can't, go into the details about signals and slots in general, and certainly not about Qt's signals and slots in particular. See them as callbacks on steroids. When something happens, for example a button is clicked, the button's clicked() signal is emitted. This, sort of, inserts a message into Qt's "message loop", and Qt then calls all connected slots. So if you connect your onQuitButtonClicked() function to the quit button's clicked() slot, Qt will call onQuitbuttonClicked whenever the quit button's clicked signal is emitted.
So:
connect(button, SIGNAL(clicked()), this, SLOT(onClicked()));
informs Qt to call this->onClicked() whenever button's clicked() signal is emitted. It does not call button->clicked() at any time, it only observes it and responds by calling this->onClicked().
I suggest you study the idea behind signals and slots in online resources, but basically it's a kind of callback system that let's you receive calls to functions when something happens. Sometimes the signal is passed through the message loop, and sometimes the slot can be called immediately from the signal, but those details are not really relevant to the concept of signals and slots.
Does Qt rely on some special C++ compiler, or special rules?
jwezorek already got a reply before I finished this, so I won't repeat much of it: no special C++ compiler, but it preprocesses your UI and source/header files using the UI and meta object compiler to generate additional source/header files that is passed to the C++ compiler.