Hi @kalemas, welcome to the forums!
My answer may unfortunately disappoint you. 
What you’re looking for is a quite common request, and the simple answer is that Pyblish isn’t an authoring tool. It’s designed for output-only, to be idempotent and not make any changes to any data whilst running. That is to say, anything that needs editing in relation to publishing needs to happen prior to even opening Pyblish, alongside other kinds of authoring, like modeling or rigging.
That said, selecting files (assuming you mean contents in a scene, like Maya) to publish is at the heart of Pyblish and it’s data-driven nature. This is what Collectors do, they identify and designate what data in a given scene, such as a model, and determine its type, or as it’s called in Pyblish, “family”. So if an artist was working on a model, your collector would correctly identify the content being worked on as a model, and apply an appropriate family - for example, models could follow some convention such as all residing in a group suffixed _MODEL or have some attribute e.g. family="model".
You then implement plug-ins to handle this family, such as model, and guide it along its path through validation all to way through extraction and integration to becoming a file on disk and entry in ftrack.
Task falls into that same category; it’s the Collector that gathers information about a scene or environment, such that if your user is working on Animation, then a collector could query whatever mechanism you or ftrack has at your disposal to determine this task. This assumes that an artist is able to choose his task separate from publishing, such as prior to launching Pyblish or via some other user interface.
In this case, you have correctly identify that the Lite (and QML) interfaces make for poor customisation, because they aren’t designed to handle any user input, other than picking collected instances and any plug-in marked as optional = True.
Have a look at how Avalon manages this, along with Pyblish Starter. I believe ftrack, like Shotgun, has some means of users choosing a task as well that I think is well suited for a collector to respond to. In a nutshell, they implement a “task picking” and “asset creation” GUI for the user in order to define what they’re working on and in what context they’re doing it. This should give you much more flexibility than anything of what Pyblish could do; because typically, and what Pyblish was designed to handle, publishing attributes need to be defined and remain constant throughout any pipeline and each version being published, and as publishing is sent across any farm. Such attributes are ideally defined and stored alongside the contents of the scene.
Hope this makes sense, and sorry to disappoint!