I did some work on MMC and DPG did some on SD with a PICAXE but neither of us have so far produced a workable or easy to use solution.
Ideal, multi-purpose interface solutions are usually 'black boxes' which can sit between a PICAXE and whatever is being controlled with a well defined protocol for the PICAXE to use which is PICAXE friendly. Those black boxes can be specialist chips, PICAXE's or other microcontrollers.
I don't see a problem with using Propellers in this way, nor discussion on how they can be used to benefit PICAXE users and how that can be best achieved. It's something I'm planning to do; to provide video output capability for the PICAXE.
Promoting Propeller as something that PICAXE users should be moving to and using instead is a different matter. It's the difference between telling a Ford car owner how to fit an Audi Turbo Charger and encouraging them to scrap the Ford and buy an Audi. People may come to the conclusion that they should perhaps be using a Propeller than a PICAXE, but I don't see that as a serious problem. The PICAXE has its advantages over others and there are plenty of people here already who could use any available micro but still choose to use a PICAXE. In fact, I can see how providing a Propeller to do things the PICAXE cannot will keep people from defecting from the PICAXE camp.
I think a Propeller-based I2C to MMC/SD interface for a PICAXE is a superb idea, especially if the MMC/SD can be made to look just like a 24LCxx I2C Eeprom for the PICAXE programmer. Go for it.
As long as the project sets out to deliver a 'solution', a circuit diagram, build and usage instructions, and a downloadable firmware image, I don't see a Propeller project any different to telling people how to use any non Rev-Ed product with a PICAXE.
When I get my Propellers, an early plan is to produce a firmware loader application so PICAXE users will not even have to use Propeller tools.