Thanks for the details. I can't go into the depth of your #2 right now but I certainly understand much better what you're trying to do. From what I'm reading, your DSL is different enough from the original Linq statement that it warrents the the custom model instead of just To-String-ifying the QueryModel as we did in the NHibernate sample. Of course, if you are already able to create everything you need from the QueryModel, there's probably no need to re-write this, except possibly because you don't like the code and/or maintainability.
With SQL, we went with the custom model because we had several additonal concepts that would need to be applied so it was easier to just start with a new model (SqlStatement).
I haven't looked at the Lucene Provider in depth, so I can't speak about the approach they took but in caase you haven't already done this, you definitely should take stock of your DSL language feature (e.g. joins, subqueries, aggregate clauses, etc) and how much optimization you will want to be able to do.
Step 6, the projection. The easiest part would be to just do entities first. That way, you don't have to do any instantiation etc and just return the result from the WebApi call. Scalar results (total count, etc) should also be pretty easy as the IQueryExecutor also offeres ExecuteScalar. The difficult part are what we call custom projections. Here, you construct an anonymous type when you actually write your linq statement and you need to instantiate this type from your result data. Unfortunately, there's not quick and easy way to do this, you will instead have to things like we do in https://github.com/re-motion/Relinq-SqlBackend/blob/develop/Core/SqlGeneration/SqlGeneratingOuterSelectExpressionVisitor.cs#L112
in VisitNew. There, we create an expression that can instantiate the target type and later on, we wrap it in a lamda, compile it and execute it. As I mentioned, it's certainly doable with only a hint of black magic, but I wouldn't recommend it for the first iteration.
Best regards, Michael