I have been able to get this to work by specifying the new compilers in the QMAKE_CC, QMAKE_CXX , and QMAKE_LINK variables. Note, specifying the same compiler binary in QMAKE_LINK is essential; otherwise you get errors like undefined reference to 'operator delete(void*, unsigned int)' because the link step continues to use the old compiler.
Another gotcha is that QMAKE_CXXFLAGS += -std=c++14 does not work. Instead, specify CONFIG += c++14. The former results in the sequence -std=c++14 -std=gnu++11 in the compiler options - where, as you can see, the gnu++11 supercedes c++14.
There is one additional thing that may be required: libstdc++.so.6 on the target will likely be pretty old as well. This will result in errors like
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.9' not found
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
when you try to run the application. These can be fixed by pointing the link /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 on the RPi to the compatible library provided with the toolchain tarball (in my case, libstdc++.so.6.0.24).
Anyway, I'm not marking this as solved because this is a hacky solution at best. You couldn't use the .pro file as-is to build for a different platform, given the hardcoded compiler paths. The real solution would be to find out why the Kit compiler paths don't work.