Not really. Sure, many languages have things like LINQ Select/Where (map/filter), but that's just for objects. It's the expression trees where things get interesting. Expression trees allow a provider to generate a different artifact than a map call over objects. LINQ to Entities creates calls which the Entity Framework turns into SQL.
You can make a custom provider against any data source, really. There is an example of LINQ to Twitter that turns LINQ queries into Twitter API calls (http://linqtotwitter.codeplex.com/).
This feature requires language support, because when an Expression is needed, the compiler needs to turn a lambda (and so on) into a expression tree, not into compiled CLR code in a closure.
To be fair, something similar could be done in other languages with proper support. And writing a LINQ provider is non trivial, but it is possible and in certain cases, it can greatly simplify programming.