An IronPython or IronRuby project can be compiled to a dll or executable just fine and will be 'real' executables in every way with the proviso that the person running them must have the relevant .Net framework and dependencies installed (dependencies may be present in the same directory by default instead but the framework must be installed). The integration with Visual Studio is still not there but projects like IronPythonStudio use the free VS Shell to good effect. The existence of the DLR as a dependency for c# dynamic in VS 2010 should mean that integration with VS from the Iron* groups becomes an easier goal and a higher priority.
The result is in no way interpreted (the CIL is jitted into machine code at runtime or via ngen if desired) and certain aspects of the DLR mean some actions are deferred in a similar fashion to latebinding but more powerfully and crucially with some sophisticated caching mechanisms to allow this to be relatively fast compared with naive interpreters.
Many traditionally interpreted scripting languages are creating their own VM based compilation strategies or leverage existing ones (like the JVM, the .Net CLR or open ones like the LLVM) since this leads to significant performance increases in many common cases.
In the case of the Iron* languages the benefit of the MS CLR as a basis is that the resulting executables 'Just Work' on the vast majority of installations of the most common OS family. Contrast to Java where a jar file is not 'runnable' by directly clicking / or 'executing' via the shell in many operating systems. The flipside from this is that this reduces interoperability compared to say a JVM or LLVM based solution where the platform support is broader but, inevitably, more diverse in OS integration.
