In principle this will work, but Bitcoin Core by default limits such chains: a transaction will not enter a Bitcoin Core node's mempool if it has more than 25 ancestors, or more than 25 descendants.
There are downsides to long transaction chains in the face of swinging feerates. Firstly, if the feerates rise, you cannot simply bump a single more urgent transaction—you'd have to bump it and all of its ancestors. Secondly, transaction chaining is somewhat incompatible with RBF—bumping any of the prior transactions breaks all the later transactions because their inputs cease to exist and you have to pay enough fees to replace the fees of all the descendant transactions to get admitted to the mempool. Thirdly, if a node's mempool runs out of space, it'll drop low feerate transactions first. If one of your prior transactions gets dropped, the entire chain following it will be inadmissible to (default) mempools until we get something like package relay, or the mempool relaxes to a level where the transaction can be rebroadcast.
Ways to work around this are to always bump the parent transactions to the targeted feerate of follow-up transactions (which is not trivial to calculate and may lead to overpayment in the case of two children to the same ancestors), or to always have exactly one output from which you chain.
In the case that you have enough transaction volume to warrant transaction chaining, I would recommend that you rather use payment batching: delay withdrawals (or other payments) by a few minutes, but then do multiple in a single transaction. Payment batching has a much smaller blockweight footprint per payment (and thus lower fees per payment), makes UTXO management much easier, because you need fewer inputs per payment, have less funds in flight because you only create a single change output per batch instead of per payment, and can maybe forgo using unconfirmed inputs altogether, which allows you to use RBF and CPFP to bump transactions when they get delayed even when you start them off with much lower feerates.
Additionally, while chaining of transactions would start to break down due to the limits on ancestry sizes, payment batching just gets more efficient with higher volume.
Secondly, will the chained transactions be mined at the same block?
Yes, if the child transaction pays a higher feerate than its ancestors, they would likely be picked as a package based on the descendant feerate. If later transactions pay the same or a lower feerate, a parent may be included without children.
