Drupal - cannot track view with features
This is bypassable by cloning the views you need from the four views that the module provides, disabling the original views, and doing all your work in your clones which are 100% trackable.
As suggested by magtak, this is circumventable by cloning the Views. They will need to be stored under a different name for this to work; exporting and importing a View (as suggested by Varshith) will only work if you do so while changing the machine name of the View. Cloning will have the same result as export/import, except that it will enforce the machine name change, and encompasses less actions.
The reason you need to do this is that these modules add Views not by entering them into the database, but adding them through code, much like what happens when you add a View to a Feature. Features will check if a View already exists in code and will not offer it for adding it to your Feature if it does. (Incidentally, what happens when you change a View that is defined by code through the interface, is that Views takes a copy of the View and enters it into the database. That's where it stores your changes. This is why you might find Views defined by modules in the database anyway; this would happen the moment you make changes to them. This is also what happens when you revert an overriden View, either from Views itself or from Features; the copy in the database is ditched and Views defaults back to the code).
One downside to the clone approach is that from that moment on, you are on your own maintaining the View that was originally added by the module; your clone is completely independent of the original, so if there are module updates that add nifty new features, you'd probably not find out. If you did, you'd have to add those changes to your clone by hand. An alternative is using hook_views_default_views_alter() to add your additions in code. However, this is completely unsupported by Features (you can add this code to a Feature; if you do so in the .module file for the Feature, Features will leave it alone when regenerating the feature). You will need to know what you are doing defining Views in code by hand. You can get a long way by comparing an export of your customized View with the original code in the module (which would be found in themodule.views_default.inc), but it is still not for the faint hearted (and may turn out to be less maintainable than just doing the clone thing).
As an aside, for Nodequeue you can certainly use the Views it adds by default, but it is hardly worth the effort to go and clone a nodequeue View. All it is is a View of Nodes, with a mandatory relation on the nodequeue, sorted by the nodequeue weight. It is probably about the same effort starting from scratch as it is cloning the default View and then making your changes.