ADC Timing Constraints

Clocks don't propagate through FFs. You'll need two generated clocks, something like so:

That doesn't seem to have done it. The TFF in my simplified schematic is actually the LSB of an always-enabled master counter called mc. I tried running the following lines through the Tcl console in Timequest.

set col ]
query_collection -all $col
create_generated_clock -name intl_adc_clk -source  -divide_by 2 $col
create_generated_clock -name adc_clk -source $col 

Go to the technology map viewer and trace back from *mc*[0] to the source. Are you sure it's directly driven by CLK_125_IN, and that has a clock on it?

CLK_125_IN goes through an IO_IBUF to become CLK_125_IN~input , then a CLKCTRL to become CLK_125_IN~inputclkctrl , both of which were inferred by the tools. I'm not quite sure what the difference between them is. (Architecture is an Arria II GX, by the way).

The IO_BUF and CLKCTRL(this is just the global driver) should not cause any problems. I'm really not sure what the issue is. If you try it with a test design, does it work?

As an aside note, why not use PLL since ADC clocked by your clock will suffer jitter and you may get around timing issues you have.

Nope, test design doesn't work. I tried the following VHDL file as the entirety of the design logic:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity temp is
	port (
		CLK_125_IN   : in std_logic;
		ADC_DATA     : in std_logic_vector(7 downto 0);
		ADC_CLK      : out std_logic;
		LATCHED_DATA : out std_logic_vector(7 downto 0)
	);
end entity temp;
architecture Behavioral of temp is
begin
	
	process (CLK_125_IN)
		variable tff : boolean;
	begin
		if rising_edge(CLK_125_IN) then
			if tff then
				LATCHED_DATA <= ADC_DATA;
				ADC_CLK <= '1';
			else
				ADC_CLK <= '0';
			end if;
			
			tff := not tff;
		end if;
	end process;
end architecture Behavioral;

set_time_format -unit ns -decimal_places 3
create_clock -name {CLK125} -period 8.000 
create_generated_clock -name {tff_clk} -source  -divide_by 2  
create_generated_clock -name {adc_clk} -source   
set_input_delay -add_delay -rise -max -clock   12.000 ]
set_input_delay -add_delay -rise -min -clock   3.900 ]
set_multicycle_path -setup -end -from    -to   2
set_multicycle_path -hold  -end -from    -to   1

Primarily I haven't been using a PLL to generate ADC_CLK because I was trying to avoid adding extra things to the situation. Also I need to control the relationship between mc[0] and the ADC_CLK. That's resolvable, but it just seems to be adding more and more complexity to the problem. I was hoping for simple instead, since even with a PLL I'd need the tools to take into account the delay between the PLL and the actual PCB tracre.

Sampling analogue signal needs very good quality clock such as that from oscillators. Practically for low Fs like 62.5 a PLL inside fpga may do. But combinatorially generated clock is doubtful and its jitter will vary from build to build and with temperature...etc.

That's the part that keeps concerning me, is that I'm sort of, kind of, halfway treating this like a source synchronous interface even though it's not quite really one.