Really ApplicationID could/should have been named SchemaID or SchemaGuid since it represents a schema. I'd name the new table mp_SchemaFeatures but use ApplicationID and FeatureGuid to be consistent with existing columns.
Populating this table should not require any changes for developers. I'm envisioning another routine that runs at the end of setup and loops through the application folders, looks up the ApplicationID (there is an existing method for this, I think it returns guid.empty if not found), and only if it exists then loop through the feature definitions and insert only if the featureGuid does not exist in the new table.
So features that have no schema/application id will not be listed in the table. Technically there still could be features that have no schema of their own nested below an application folder that may have a schema to support other features. ie the app folder has some features that have sql scripts and some that don't. So it is still a very loose relationship since there is no guarantee that a given feature guid nested below the app folder is really related to the schema. Only if all the app features below an app folder were deleted would it really be safe to remove the schema unless you know by other means which ones really use the schema.
To be honest I don't see any huge advantage to adding this extra table that will rarely be used, seems like make work to me. The method signatures would have to exist for all supported db platforms so the methods should probably be voids with no return types like
public void AddSchemaFeatureIfNotExists(Guid applicationGuid, Guid featureGuid)
that way they don't really have to be implemented for all data layers, the method could do nothing in some data layers.