[Galaxy S 4 Q&A, Help & Troubleshooting] Steve_max:
You say you have a MsC (in which field, BTW?); I actually have a PhD in high energy physics. Let's discuss this on an academic level, then?

You are talking about emulating a RISC architecture on a different RISC architecture. Also, you must remember that the 360's POWER arch was designed and developed for high computational power, even if the total system power goes up; while the S4's ARM was designed and developed for high efficiency (this is why ARM kicks Intel's ass on phones, BTW: Atom just can't scale down in electric power as low as ARM, so battery usage for Intel phones is worse than for ARM phones with equivalent performance).

Emulating RISC architectures is somewhat easy. Emulating ON RISC architectures is hard. You usually can't map one instruction from the source arch to one instruction in the destination arch. This gives you timing issues that are very, very hard to solve; specially when the software was designed for a fixed hardware, where you can map exactly how long a given instruction should take to execute. Changing that is Bad. This means you need to throw A LOT of hardware at the problem. And a single A15/Krait300 core is not "a lot" faster than a single PPC core.

You also can't change threading. On the 360, software is developed to run on six separate threads (3 cores, two threads per core); the current quad/"octa" mobile CPUs have four active cores and one thread per core, for a total of 4 separate threads at a time. You're missing two threads. Again, you can work this out, but you'd need each core to be at least twice as fast as a PPC core (assuming you could get the code to run under ARM as efficiently as under PPC, which we saw on the last paragraph that is impossible).

So, with only four cores, you'd need each core to be at least four times as fast as a PPC core; and that's without taking into account the rest of the system (the Android OS running) and the translation layer, which is actually the hard part. So, summing it all up, you'd need four cores running about 10 times faster than each PPC core on the 360 to be able to run a well-optimized emulator at a decent speed. However, each A15/Krait300 core is at the same speed level as the PPC cores from the 360. We are very, very far from emulating a 360 on a mobile.

Also, note that throwing more cores helps a bit (ideally, you should have one core per thread of emulated code, plus a few cores for the rest of the system to run), but after some point it becomes useless. Eight cores running at the same time would help. Twelve would be the optimal value, probably. Going from 12 to 16 cores wouldn't help much: you really need to increase single-threaded performance, while the current trend is to increase multi-threaded performance first, and single-threaded performance as a side result. This also means we are even farther from a 360 emulator.

And I didn't even touch the GPU part, where Android exposes a GL-based interface and the 360 exposes a DX-based one. And we moved to programmable GPUs around the time the 360 appeared (but its GPU is still fixed-function), which is another complication. The bottom line is that our GPU is basically as fast as the 360's (see the Anandtech article people have linked here), but translating the 360's functions to the Adreno/PowerVR GPUs while keeping sync is very, very hard. Hard means that the CPU and GPU need to do a lot of additional work, so they need to be way faster...

TL;DR version: No it can't, unless it's recompiled by the developer. We are farther from an usable 360 emulator than most people realize, due to its multithreaded arch. Your masters' degree should have taught you how to research into things like this before asking such a clearly stupid question.