Are you reading the data inside a transaction? If so, these are read locks.
LLBLGen Pro isn't doing anything odd, it just formulates normal queries and executes them using normal ADO.NET commands, without weird constructs.
Could you also check with the SqlServer profiler to see what # of locks and what TYPE of locks are created? SqlServer places read locks on rows when you fetch them. This is normal.
If you want fetches performed with the NOLOCK hint, please enable NOLOCK using the static property on the SqlServerDQE's DynamicQueryEngine class.
When I run different kind of fetches in bulk, not in a transaction, on our Sqlserver 2000 database, using llblgen pro v2.5 code or normal ado.net code (datareader and datatable), I get 500-800 locks/sec for llblgen pro code and 1100-2500 locks/sec for datareader/datatable code.
This is normal as the overhead for these two types is less than the llblgen pro code so there are more queries executed per second.