I think there should be a flag in the NDS ROM file that allows me to enable EEPROM support.
As far as I know, this is not how this works. When a "professional" developer masters a game, he/she doesn't simply send the rom to Nintendo for QA and "ship it". When the cartridge based distribution is chosen - as common on NDS - he also would order Nintendo to manufacture Cartridges of the chosen type determined in the order formular. Therefore, there would be no need for such a header flag - and as homebrew documents state, there is no such flag:
https://dsibrew.org/wiki/DSi_Cartridge_Header
Even though Nintendo uses devkits that support multiple memory types for quality assurance, this is usually communicated in advance in the Quality Assurance Request Form.
In addition, most games seem to use the EEPROM memory type anyway, so emulators usually check the cartridge header, especially CRC32 and game code, and match it against lists of games with different memory types. Homebrew titles must therefore use an individual setting here if they neither use EEPROM or libfat.
You might want to have a look at
https://github.com/TASVideos/desmume/blob/master/desmume/src/saves.cpp and
https://github.com/TASVideos/desmume/blob/master/desmume/src/slot1.cpp as those seem to handle how Desmume handle the Slot1- / Card-Interface and therefore also handles the savegame management. As how I read those lines, desmume does "not really care" about which type of storage would be behind the save interface of Slot1, as long as it can detect the cartridge as being of type 0x01, NDS_SLOT1_RETAIL_MCROM, which would contain a eeprom / flash / fram savegame storage.
Homebrew might get loaded with different settings. As I dont have the ability to run desmume currently, I am unable to do more help than guessing based on the code. But it seems, this might be another nail in the coffin, why homebrew-developers usually recommend to use libfat, as it seems that desmume and other emulators simply assume a cartridge without any save storage used by homebrew.
However, it seems as there is also another cartridge type, 0x02 NDS_SLOT1_RETAIL_NAND used by Wario Ware DIY, which seems to be overwritable nand-flash, which would allow the cartridge to be updates as well. It seems like this game is a very special and problematic case amongst the emulators and flashcards and therefore - as it is usually the "only" game to do so - gets specific patches, as the save mechanic is heavily woven into the game code on the ARM9.
Desmume even had a subclass for handling this:
https://github.com/masterfeizz/DeSmuME/blob/master/src/addons/slot1_retail_nand.cpp
But I dont think this is suitable for your usecase, however it might be a noteworthy mention, as searching for "flash" in context of nds might become confusing, as both flash-roms as well as nand-flash are considered to be "flash". I guess it would be better to search for how to access the sram / eeprom, as the mechanic is nearly identical.
For desmume, there seem to be "dev+"-Builds according to their forum, which would allow you to set a specific save type and size.
Then, the example should be able to detect the chosen storage media.