Many of these databases are created
and rarely, if ever, edited.
If this is the case, then you will not get a whole lot of benefit out of Subversion. It is a version control system, not a backup system. You will not be wanting to do version control operations like diff, merge, etc on the objects, so I think you will get better mileage out of a traditional backup method. Compress the sqlite files (as much as you can) and archive them for a specified length of time. If you are running this on a Linux system, you can look at backup scripts like the logrotate scripts that do the same thing for system logs. Since sqlite databases are nice and cleanly packaged in a single file, restoring an old version can be easily scripted (just un-compress and copy to the correct location).
Depending on how much data each user is storing in their database, one additional alternative is to keep shadow copies of tables in your repository. When a change is made, a copy is made of the old table before it is modified. This way you can keep a copy of the previous (or even the last several) revision(s) in the database and can restore them with a simple database operation instead of having to go digging out old backups. This also lets you revert changes to part of the database without reverting the entire thing.