Note: I’m talking hypothetically here; this is not something I’ve actually tried to do.
With that said, yes, if you LUKS encrypt the special AND you don’t exhaust the special, your metadata will be encrypted. Of course, you also won’t be able to mount the pool until after LUKS unlocks the special, but that seems reasonably workable.
But let’s circle back to that “as long as you don’t exhaust the special” caveat. If you run out of room on your special vdev–for example, because you wound up storing incredible numbers of small files (requiring vastly more metadata than the same amount of data in fewer but larger individual files), or because you set special_small_blocks and didn’t realize just how many small blocks you’d end up writing–then ZFS will silently start saving metadata (and small_blocks, if applicable) to the main storage, where it won’t be encrypted at rest.
This is not a purely hypothetical concern; special exhaustion absolutely can and does happen, and absent your clever LUKS trick, the only real impact is that you lose the performance boost normally given by the special. On rust pools with very heavy loading, this can in fact be a crippling performance surprise, but the impact is limited to performance.
However, with your trick of LUKS encrypting the special to encrypt your metadata at rest, you open up a hole in that scheme. Now, if you fill up the special, you not only have a performance impact, you start leaking metadata.
How important is that? Well, personally, I was never really worried about the metadata being in the clear anyway. There’s not much risk, in my opinion, in somebody being able to see the names of my datasets and snapshots. But I don’t know what risk assessment you’ve used to determine this is something you want to pursue, so you need to figure out for yourself how much of an issue the potential metadata leak–and how you’ll monitor to detect if it’s likely to happen, and if it has happened–really is, in your own specific circumstances.