Well, I have not seen your project or data model, so you will have to interpret this as the most appropriate for your situation. However, yes, my reaction is that this is more code than necessary.
One of the main advantages of using ORMs like NHibernate is that they separate your code from your persistence architecture. It seems to me that displaying a NewsItem (for example) several times is not necessary, for one. Can't the data model be the same regardless of the backend? Perhaps you could give an example of where they might differ.
Secondly, I probably wouldn’t repeat the implementation of NewsItemRepository. Regardless of the database, NHibernate is used in the repository, the purpose of which is to abstract the database. All CRUD functions processed by the repository will be the same in MSSQL as SQLite (unless there really is a difference in the data model).
If your database model is the same for both parties, theoretically you only need to change the connection string to change the database used. The way I implemented DAL is to provide interfaces, as you did, and then have a namespace for implementations, one (well, the only one for now) that is NHibernate. Repositories and others are obtained by dependency injection. The DI core also handles session factories, so it's easy to target a different database for different sections of the code.
Of course, all this assumes that your data model is the same for both database engines. If not, my answer may not be very helpful. If this is the case, knowing that something else can lead me or someone else to a better answer.
EDIT:
I understand what you mean about sql type. However, this is only a problem if you generate a schema for your database from NHibernate. When mapping properties, you do not need to use <column> , and the type you specify on <property> is the type of NHibernate. The StringClob type correctly processes NTEXT fields.
If you are generating your schema from NHibernate mappings and NHibernate is not smart enough to exclude sql-type = "NTEXT" for SQLite (I hope so, but I never used the schema generation tool), I think I would add a step Builds to clean SQLite schemas. Of course, now you add complexity to your process, so it is up to you. However, I prefer that my code and mappings be as simple and clean as possible and only keep complexity where necessary (detailed information about the database engine). It seems to me that saving two separate mapping files is a recipe for not matching properties, and users have left scratching their heads about why they cannot use DOB when using SQLite;)
EDIT2 (regarding the use of DI with NH):
This is a bit subjective since I'm sure there are many ways to use DI with NHibernate. I have had great success using DI with Fluent NHibernate and Ninject , a DI framework that also uses smooth DSL. Fluent NHibernate (FNH) provides the IPersistenceConfigurer interface, which is used to create your database connection string (it also provides a number of dialects to choose from). Thus, it is easy to bind this IPersistenceConfigurer service to a provider through a DI framework. You can do the same for ISessionFactory to have a fully D-nested factory. Since Ninject works with attributes, my repository constructor might look like this:
[Inject, CRM] public MyRepository(ISessionFactory sessionFactory)
To enter a factory for the CRM database. I like.:)