(classes not created by the LINQ ORM Designer)
Supposing you want to return results as a list of custom classes. You can use the executeQuery here with custom sql statements.
Example : (this example is in VB.net, for c#, head over to ScottGu’s comprehensive linq page HERE)
This is how your custom class (you can also think of it as your entity class) may look like : In my example, my custom class : RiskLoadingSummary is a scaled down version of the RiskLoading table mapped in the data context designer. (Lets say RiskLoading is a class that maps all the fields in the table called RiskLoading, and RiskLoadingSummary, only maps 3 fields from the table)
(LINQ to SQL ORM generated class table in data context designer view) :

My Custom class : 3 properties mapped to 3 fields in the table.

Steps :
Extend your DataContext with a partial-class code behind file : (executequery will autopopulate all the properties based on your sql statement)
Let’s say your datacontext name is NorthWindDataContext (name auto generated and you’re using the NorthWind database). You’ll create a new separate class file in the same project as where your datacontext resides. This class file will extends the NorthwindDataContext by using the “Partial” statement. You may name it something like NorthWindDataContext_Extender.cs (or .vb, depending on your language). Then just enter the line of function code below:
Partial Public Class NorthWindDataContext
Public Function GetSummary(ByVal intVersion As Integer) As List(Of RiskLoadingSummary)
Return ExecuteQuery(Of RiskLoadingSummary)("Select Version, Score, SystemId from RiskLoading where Version={0}", intVersion).ToList
End Function
End Class
Save and compile. After that, when you declare your data context object as below, you may call the new function that you have written to populate for you a list of custom class based on the data you have selected with your ExecuteQuery statement. The reason that you create a new class file and not stick this function into your datacontext autogenerated file is to prevent future overwrite when visual studio regenerates the code behind.

References :
http://oakleafblog.blogspot.com/2007/09/problems-using-stored-procedures-for_08.html
http://www.rocksthoughts.com/blog/archive/2008/03/03/delete-multiple-rows-with-linq-to-sql.aspx
http://weblogs.asp.net/jeffreyzhao/archive/2008/03/06/linq-to-sql-extension-batch-deletion-by-lambda-expression.aspx