You'll need the second NIC in a different subnet in order for Windows routing to be happy. Then, TMG NATs between the internal subnet, and the external subnet (using the Edge layout anyway).
To push all traffic through the TMG box, point clients to it as the default gateway. It's likely to be a fairly major change to how the network works at the moment, so have a rollback strategy.
In order to do this most easily (but with a significant change), switch the current D.G. to a different subnet (say, a 10.x subnet so it's nice and visually differentiated), plug the other TMG adapter into that subnet, and allow that subnet to be considered external by TMG (i.e. do not include it as an "internal" network) - that way, anything not in the currently-defined Internal IP range will be considered potentially hostile. (Or at least External; TMG doesn't trust Internal networks implicitly).
The 10.x network essentially becomes a DMZ of sorts - your router (I assume is currently NATting to the ISP) can forward incoming requests to the external interface on the TMG box, and TMG firewall policy will control all traffic into and out of the 192.168.1.x network.
For ease of migration, if you go with that, the internal interface of TMG should assume the old IP of the router, i.e. the already-configured-on-clients default gateway.
For advanced Web use, i.e. authentication if required, configure WPAD to give clients explicit knowledge of the proxy.
Alternatively, leave everything as it is, ignore the second NIC, and use TMG as an explicit web proxy, configured either as http://tmg:8080 on clients, or through WPAD. It won't do whole-network content filtering, but it will at least do web traffic scanning in that configuration, and allow you time to get more familiar with it before embarking on the Massive Outage Path.
Better still, test your intended setup using a lab or virtual machines.
Just a thought.
Edit: One more very, very general tip: At some point, you're going to be tempted to create a rule that says "Allow anything anywhere anytime". If you do succumb to that temptation, make sure you exclude the Local Host network from it, so that at least TMG is still performing some local packet filtering to defend itself from nasty internal/external clients. (NAT tends to take care of most incoming traffic from outside, but there's always external misconfiguration to worry about).
If you want TMG to be able to connect to, or be connected to by, something, System Policy is where to do that. And as another-nother tip, if you don't allow any incoming connections to TMG other than RDP, you'll basically* be able to ignore* most* security updates* that are released*. Which is nice for the uptime. Plus! NIS gets updates when MSRC release bulletins, so there's an additional level of protection there too. Just don't get complacent.
' * - don't do this.
You're correct that FileZilla or WinSCP are needed. Basically those FTP settings say that anyone trying to use the normal method over port 21 should be denied, and it doesn't attempt to reestablish a different type of connection. Thus IE and the command line options won't work.
A good test is to install FileZilla locally on the FTP server, or on another server that doesn't have a firewall in-between. Get it working there to prove that it works, and then start looking at your firewall policy to allow it through. Most likely you're running again a firewall rule that blocks the dynamic ports necessary for FTPS.
In FileZilla, use "explicit FTP over TLS" and test using active and passive mode. Active and passive require different firewall ports.
Best Answer
TMG doesn't support FTPS (that's FTP + SSL, rather than SFTP, or SSH File Transfer, which generally works fine)
FTPS is Really Hard to do with an FTP filter, because the FTP NAT filter watches for information the client behind NAT sends to the FTP server, and encryption causes that not to be visible. And that annoys NAT inspectors.
If Total Commander supports using HTTP proxies, you can work around this fairly easily by configuring it to use an HTTPS connection instead (via ye olde CONNECT-to-get-a-plain-TCP-channel hack).
For that to work, you'll also need to configure TunnelPortRanges to allow the destination port as if it were SSL. http://technet.microsoft.com/en-us/library/cc302450.aspx
Alternative alternative!
If (long list here)
then you could set up
And this set of rules should be ordered before any other rules allowing the client full access to all protocols and ports.
It's important the DENY FTP rule is
a) immediately after the Special FTP rule that uses the protocol with the application filter unbound, and
b) before any other rules that might allow the client to use Good Old FTP to the target IP (otherwise TMG prefers the protocol definition with the application filter, which is what we don't want here - we want TMG to treat it like straight TCP)
I think this would cover all the FTPS scenarios. Same principle as this.