"Custom kernel designed for responsiveness"

As an example I saw when reading somewhere, in Windows one Window is ran in a thread while in BeOS (which I imagine this carried over to Haiku) every individual GUI Object has its own thread. The example being that clicking a button in Windows could freeze the entire Window but clicking a button in BeOS would only freeze that particular button.
You are wrong. In Windows by default threre are only one thread for application with all it's windows(but you can create additional threads and process windows in this threads). In BeOS and Haiku application and every window have it's own thread. Also for each window threre are separate processing thread in app_server. This threads process graphics and messages. You can watch running threads in ProcessController application.

However, even with this approach -- would it be the kernel providing this mechanism or some sort of a GUI layer? I still don't have a very in-depth knowledge on Haiku's architecture so feel free to correct me if I'm wrong.
GUI mechanism is implemented in user mode in app_server, input_server and registrar. Kernel don't know anything about graphics(except splash screen during boot).

Is there anything specific the Haiku kernel does for responsiveness that other modern kernels don't do?
For now all kernels are mostly similar and implement the same functionality, but diffrent kernels are optimized for diffrent purposes. Haiku kernel has special thread sheduler for responsiveness. It work on thread level, not on process level. Also Haiku kernel heavily use ports - commucation streams, that allow to transmit and receive data between kernel and programs or by diffrent programs. Ports are quite fast. For best speed Haiku drivers are divided into 2 parts: kernel part and user part. Kernel part simply give access to hardware and user part actually control hardware. For example 3D accelerated applications can use user driver(accelerant) in its own address space minimizing communication overhead.

Also as I know BeOS was first system, that can use SMP in efficient way. Scheduler is a main point. It can handle real-time and time-sharing threads with wide gradation of priorities. Threads with the same priorities are executed with same speed, if one thread have one bigger than other it's speed will be doubled other thread speed. So thread execution speed is propotional to 2 in thread priority power. Real-time threads just take execution if active and there are no active real-time threads with higher priorities. If thread was unlocked by other thread it will be switched immediately. Sheduler quantum time is 3 milliseconds.

This is theory. Haiku can have bugs or incomplete implementation so lags can appear. For my look Haiku responsiveness is better than Windows. Windows Vista, 7 and 8 just freeze sometime for seconds I don't know why. Linux kernel has notorious bug that cause system slowdown when IO activity is high.

I found an article how this works long time ago, but I forgot link.