Well, I said "closer", not an exact analogue. They're pretty close equivalents, though, as most Windows programs don't actually call syscalls directly, but link in an OS-provided DLL and call an exported symbol from it, with the userspace to kernel bits abstracted away from most user programs. Wine (mostly) re-implements those DLLs, effectively re-implementing the Win32 API (a userspace API) in Linux's userland.

(programs are allowed to call the kernel directly, though, and Wine has to handle those cases esp. for DRM/anti-cheat code in games that poke at the kernel directly, recently Linux was patched to allow userspace programs to directly handle syscalls [0][1], making Wine ... closer to a WSL1 equivalent?)

[0] https://lkml.org/lkml/2020/8/10/1323

[1] https://github.com/torvalds/linux/blob/master/include/linux/...

Neither reimplemented the other syscalls directly in the kernel. In WSL1 the NT kernel kicked Linux syscalls to an lxcore.sys driver to convert them into equivalent NT calls and objects. In WINE most things don't make direct syscalls (they make userspace Win32 calls and WINE reimplements that and many other Windows APIs in a way that calls Linux syscalls directly) but for those that do (e.g. game DRM) the Linux kernel added a SECCOMP_MODE_MMAP mode to seccomp() to trap unknown syscalls to a handler (in this case WINE) to do the same thing.

As far as I understand Wine does way, way more than that. Wine actually re-implements all Windows API's. Not syscalls, but higher level libraries like DirectX and whatnot.