В качестве консолидированной базы все что угодно подойдет.
Читать учебники по ключевым словам replication, data consolidation, data migration, ETL.

Существует множество ETL инструментов и наверное есть уже готовые к работе с Android-SQLite удаленными базами, но я таких пока не встречал.

В самом примитиве: добавь в свое андроид-приложение операции выгрузка базы в файл и загрузка из него. В качестве файла может быть все что угодно, хоть набор CSV/DBF файлов для таблиц и JPG/BINDUMP для блобов (просто заменяй в csv данные блоба на имя файла с данными этого блоба). Пакуешь весь набор файлов в архив - и получаешь пакет для консолидированной базы.
Как вариант предыдущего - используй XML, а блобы пихай в тот-же файл в UUE/Base64 кодировке.
Соответственно на десктопе тебе нужна будет пара аналогичных функций для разбора этих архивов в удобный для консолидированной БД формат и создания выгрузок для конкретных мобильных клиентов.

Более продвинутый вариант: делаешь сервер, придумываешь для него API (типа "я юзер номер 1", "прими мои обновления", "дай данные для меня из большой базы") и твои мобильные клиенты будут подключаться к главной базе и используя это API синхронизировать свои локальные базы.

shuriktпромежуточная база,
...
Т.е. хотелось работать на уровне записей баз данных. Насколько он применим в данной ситуации?
Это один из самых сложных в реализации и ненадежных методов.
Промежуточная база предполагает что клиент с локальной микро-базой, подключится к консолидированной (или прокси) базе напрямую и будет перекидывать данные простыми sql запросами. В теории это просто и удобно, но только в теории.
Этот подход требует прямого подключения к консолидированной БД. Если по секьюрити причинам БД сидит за файрволом - надо будет поднимать прокси БД. Что сводит к нулю смысл пряток за файрволом.
Но самая главная проблема: клиент посылает прямые SQL-запросы в консолидированную БД. Это огромное и слабо контролируемая дыра для sql-injection.

tchingizи через полгода начать бороться с разделителем внутри поляНу я же сказал: "в самом примитиве" :)
Тем не менее, у меня такая схема лет десять жила еще на Clipper, потом к ней (не меняя формата обменного файла) добавилась "большая SQL-способная СУБД" и пока все филиалы не перевели на новую платформу (да и потом еще пару лет) агенты в главном офисе и филиалах кидали на FTP сервер файлы обмена. А потом перевили на родную для СУБД ETL систему (то есть перешли на "сервисный" вариант).

Да и сейчас у меня есть пара баз (MS SQL Sever 2008 и Adaptive Server Enterprise 15.0.3) которые между собой гоняют данные через CSV (bcp out/bcp in). Очень просто настроить, и если не пытаться гонять блобы через тот-же bcp, а чуть-чуть поднапрячься и написать специальную "blob out/blob in" утилитку, проблемы с разделителями просто не возникают.