Don't think you can use hexagonal architecture to do your design for you, there are still decisions to be made around what sits where. But do take into consideration that the whole idea of hexagonal architecture is that the core/domain/central hexagon shouldn't need to change if the outside world does.
There is absolutely nothing wrong with your core taking in multiple business objects and doing some transformation into another object (maybe, keep reading).
What it shouldn't be doing is things like XML to JSON transformation or specialising the output of a request because of the requestors implementation.
So for your UI related questions. You can have a UI model in your core, and you can do calculations in your core to fill out that UI model. But even if you have several UIs (e.g. website and native apps), you still have one UI model in the core. Filtering data or UI implementation specific calculations are a problem for the adapters or maybe the actual UI. Don't take this too literally, if you have two very different views of your data, then by all means cater for that in the core.
The question about requiring calls to two different databases to do some business logic is not so cut and dry. If the fact that there are two databases instead of one is an implementation choice, then the adapter should be giving the core one object. If those databases are very different things and you'd never seriously consider consolidating them into one database, then it's perfectly acceptable for the core to know that there are two things with seperate ports/adapters.