I've kind of done this, just without the actual "build" part—I instead use a Wooting computer keyboard (which has the hall effect switches you're referring to), and I've written some program to emit MIDI based on key velocity.
I've been using it very frequently for a few years, and can confirm it's quite fun to use, though I don't have much experience playing other keyboard instruments and haven't tried to learn it seriously enough to make proper use of chords etc.
The layout I use is not a regular piano layout, but a B-griff layout, as used on a bayan (Russian accordion). I made a demo site for playing with the layout (keyboard or touchscreen), but without velocity sensitivity: https://maxdamantus.gitlab.io/bayan/
The B-griff/C-griff layouts naturally fit computer keyboards, and I'd argue they're better in general than piano layouts for various reasons. There's also this cool video of someone using two Commodores for similar effect: https://youtube.com/watch?v=EBCYvoC4muc
Some mechanical keyboard firmware already supports midi. I don't think any supports velocity, but they would likely welcome the code if you wrote it. They already support these switches, so it seems workable.
No, it's on the software (computer) side. It's not in the demo site because I created that in 2019 [0] for use with a regular keyboard (since I was having issues with the software I'd previously been using for playing MIDI). I only upgraded to the Wooting keyboard in late 2021.
I've been meaning to look into adding Wooting support, just haven't got round to it. This would require either WebUSB or WebHID which are still "experimental", and I'm not sure if there will be latency issues.
The program I created for computing velocity and emitting MIDI is here [1]. When it's listening for keyboard data it does it in another thread so that it can attach fairly accurate timestamps to the key events, without being subject to pauses from Gtk or something. If there's inconsistency between the key event times and the relative timestamps, the velocity detection can be noticably off. I've noticed this in Wooting's own MIDI application [2]. Hopefully WebUSB/WebHID includes timestamps in the data, so it doesn't have to be subject to JS GC pauses.
As well as the Rust program above (possibly Linux-only, though should be easily adaptable to work on Windows/macOS), I've written an Android app that does the same thing so I can use it without a computer (though in Android you have to take control of the USB device rather than just read the HID data), but I haven't uploaded the code anywhere.
[2] https://github.com/WootingKb/wooting-analog-midi ... as well as issues with timestamp jitter, this application seems overall a bit bloated for my taste (web-based app using Tauri), and it's inconvenient since it will continue to generate MIDI when you're focused on other applications, so you'd have to close and open it (slow startup time too) each time you want to use it. their timestamp jitter occurs because the Wooting SDK (at least at the time, haven't looked at it recently) worked by running a thread that would update a shared HashMap and you would have to poll that hash map; it wasn't possible to see all updates, and there were no timestamps attached. I avoided the SDK and instead just read the data directly from the "hidraw" device.
I want to try to build a hardware midi keyboard using mechanical hall effect switches like this: https://mechanicalkeyboards.com/products/wuque-studio-dash-5...
There's a few physical keyboards out there but many are super super expensive.