Wiring up lots of switches is easy.
The hard part is making the switches look like a hardware device which the Mac version of the X-Plane 10 software will listen to. (AFAICT, you don't know of any such device. Yes?)
As a software developer, I assume you understand that the game will only interact in specific ways with specific hardware devices. It can't magically talk to something it wasn't programmed to interact with. So if X-Plane-on-Mac doesn't support reading messages to directly control switches, then it is going to be practically impossible.
Preferably the game will talk to a USB device, and that USB device will be a common standard device which Mac OS X already supports.
(Are their keyboard shortcuts which change switches in the Mac version of X-Plane? If their are, it should be straightforward.)
Edit 2:
You've confirmed, there are keyboard and joystick shortcuts to control all of the switches you need to control.
So assuming that is a none-proprietary keyboard (reasonable), then you need to implement a USB HID device (as other answers say).
There are a bunch of approaches:
The most compact, neatest, solution would be Paul Stoffgren's Teensy USB boards; I think his work is outstanding. Also, for alternatives, Adafruit's ATmega32u4 Breakout Board and Sparkfun's Pro Micro
Sparkfun's Pro Micro link is an article showing how to emulate a USB HID keyboard, and send characters when pins are grounded (e.g. using a switch). This seems like a very good place to start.
Once you read and understand that, you can choose a bunch of ways to implement your hardware, using the list of options above.
The Arduino UNO with its built in ATmega16u2, might be easiest to get hold of; my local electronics store have them, or electronics distributers with next day delivery. There appears to be lots of information on the web too.
Note: Arduino-Nano hasn't got an ATmega8u2/ATmega16u2/ATmega32u4, so it is not suitable.
If the keyboard or joystick are proprietary, then read on ...
From a USB host system's view, USB hardware (devices) come in many 'flavours'. Each 'flavour' is a different type of hardware device. Each type of hardware device only implements a specific conversation with the host. The host OS needs to be prepared to have lots of different types of conversations with USB devices. The OS uses a device driver to do some of that work.
For example, USB mouse or keyboard (HID, Human Interface Device) is different from USB Flash drive, different from a USB CDC, etc. Mac OS X has device drivers that can interact with a USB HID devices, different device drivers for USB CDC, others for USB Flash drives, etc.
Some types of USB device are easy to build, some are hard. An OS will have device drivers for many standard USB devices. A game author could use a standard USB device. But that doesn't seem to fit with the "I was told by the manufacturer that the product is not compatible with Mac." comment. Try to get hold of the Windows USB device and try it on your Mac.
A way to 'lock' the USB device to the game is have a proprietary 'conversation' with their own USB device over that communication channel. So the USB hardware device might appear to be a standard USB device, and it may even work with other games, but it might share a secret conversation with its game, preventing other similar USB devices from other vendors working with their game.
Edit:
If X-Plane-on-Mac doesn't seem to work with a USB device that works with X-Plane-on-Windows, then X-Plane-on-Mac might not expect switches from a standard USB HID (Human Interface Device). This is probably the first thing to get clear.
Worse case; the author of the game may have decided to use some weird non-standard way to talk to, e.g. a game-controller, which only they sell, to make it harder to pirate a game, and to get extra income from sales of the game controller.
If it isn't USB, or a very simple technology that can be connected via USB, then it will likely be hard on Mac OS X.
The comments "Unfortunately, the circuit board is not compatible with Mac OS." and " I was told by the manufacturer that the product is not compatible with Mac." makes me suspect that the manufacturer may have done something to restrict the use of the 'switches' game controller.
It may be innocent, and it is just that Mac OS X does something weird when it sees the device.
So, figuring out exactly what game controller the game can use is crucial. It may be a standard USB device, or it might be deliberately perverse. Until you find a product, which works with your game while running on Mac OS X, there is no reason to believe that it is possible.
It might be possible to keep the game happy, and fool it into thinking it is talking to a special device. I imagine carefully worded web searches might find that information. However the game publisher may go after anyone publishing ways to subvert their technology, so that information may be hard to track down.
So you are going to need to do some research and detective work.
You might be able to find forums where people have used a third party games controller (i.e. set of switches) to work with your game.
To become familiar with some of the terminology, you might try Wikipedia, USB, "System Design".
You might also look at DTrace, which is a technology built into Mac OS X which might help you see enough of how the game interacts with USB devices to achieve your goal. For this to be useful, you'd need to have access to a Mac, running the game, and that needs to successfully listen to a product which behaves like a set of switches.
I don't want to dampen your enthusiasm. I might be wrong, and misunderstood what you are trying to do, or ow hard it might be to do.
However, unless it is much easier than you are making it sound, I think you need to find someone who has done something similar already, or can help you figure out the software/communication part of the problem. Otherwise it will be hard. I have done some simple reverse engineering of USB conversations (without hardware tools like a USB-sniffer), but with a well understood USB device, involving Open Source software (though so exotic it was slow to see exactly what was happening). Even that took days, and I understood quite a lot of stuff that you seem very unfamiliar with.
Edit:
If you can get hold of a 'USB sniffer' (low-speed may be enough), then you can see what the game is exchanging with the USB device. A USB sniffer inserts in the USB connection between host and device, and sends all the data to PC. It is brilliant for reverse-engineering higher-level USB communication.
If you can't get a USB sniffer, then one technique which may help nail the protocol is to run Windows & the game in a virtual machine, and try to observe its interaction with the USB device via the underlying operating system. I haven't tried it, but it might work on your Mac using DTrace to observe the communication.
Another technique is to make a 'poor-mans' DIY USB sniffer. It won't be as good as the real product, but would be lower-cost, and may be enough. Use a programmable device, which can emulate different USB devices, with several different devices already implemented. Look at LUFA which implements quite a few USB protocols, and Paul Stoffgren's Teensy USB boards, which use some of the LIFA libraries. The benefit of getting this to work is the same device could also be used to make your switch panel.
Whatever hardware you choose, it needs enough speed and memory and a USB device library, to pretend to be the USB device the game wants to see. It will also send everything (maybe over a serial-to-USB) to a monitoring PC. It may be trial and error, but unless the game is insanely profitable (in which case they may do something very weird), the USB device the game expects is likely to be something very standard with an extra bit of stuff on top.
